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(54) Tide: METHOD AND SYSTEM FOR CONDUCTING ELECTRONIC COMMERCE TRANSACTIONS 
(57) Abstract 

A system and method for conducting electronic payment transactions accepts and stores information describing an item sold by a 
merchant on a commerce server. The merchant also defines payment processing rules that define the payment methods accepted by the 
merchant. The merchant, in turn, is provided with a reference identifying the commerce server and the item. The merchant preferably 
publishes this reference at the merchant's web site on a web page offering the item for sale. A customer viewing the merchant's web site 
indicates a desire to purchase the item by selecting the reference. As a result, the customer is put in contact with the commerce server and 
is provided with information from the commerce server about the item and is given a list of payment options. The customer preferably 
selects a payment option and provides the commerce server with payment information, such as a credit card number. In response, the 
commerce server contacts a selected payment system and completes the electronic commerce transaction. The commerce server then notifies 
the customer and the merchant of the results of the electronic commerce transaction and delivers the item to the customer. 
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Background 

Field of the Invention 

This invention pertains in general to electronic commerce and in particular to a method 
10 and system for conducting electronic payment transactions via the Internet. 



Background of the Invention 

Electronic commerce conducted over the Internet has become increasingly important 
over the last decade. Online merchants offer goods and services for sale or rent including 

1 5 physical objects such as compact disks, books, and clothing, and intellectual property such as 
streaming music and movies and electronic books. Physical items may be delivered to the 
customer via the mail or a variety of other shipping options. Intellectual property, in contrast, 
may be delivered to the customer by allowing a download via the file transfer protocol 
("FTP"), providing the customer with an access key, establishing a telnet session, or through 

20 some other form of electronic delivery. 

Typically, these goods and services are displayed on the merchant's web site and a 
prospective customer views, selects, and purchases the goods using web browsing software 
such as NETSCAPE NAVIGATOR* The customer usually pays for a product by establishing 
a secure connection with the merchant's web server and transmitting payment information, 

25 such as a credit card number, to the merchant. The merchant then uses back-end processing to 
verify the payment information and receive payment. For example, the merchant may use a 
secure telephone line or network link to contact the credit card issuer before accepting the 
customer's order. Eventually, the merchant and credit card issuer settle payment and the 
merchant delivers the product or service to the customer. 

30 a difficulty with the above-described scenario is that each merchant must implement an 

inventory and payment database and a payment acceptance and verification system. For 
example, the merchant must establish and maintain a database tracking sales, delivery, and 
payment information and product inventories in order to support the electronic commerce 
system. There is significant cost and complexity in maintaining this database, including the 

35 difficulty of integrating it with legacy accounting and fulfillment systems and aggravated by 
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The United Parcel Service has ac- 
tivated the first nationwide mo- 
bile data service using cellular 
technology, permitting the 
company to transmit delivery infor- 
mation from its 50,000 delivery vehi- 
cles for immediate customer access. 

UPS created the system by form- 
ing the first aJliance of fifty public 
cellular carriers throughout the 
country to provide a common data 
service, all connecting With UPS's 
own private global telecommunica- 
tions network, UPSnet The system, 
which was implemented at a cost of 
about 3)50 million, is the largest of 
its kind in the world. UPS selected 
cellular over the other network alter- 
natives because it provided the most 
extensive geographic coverage, high- 
est reliability, and potential for fu- 
ture upgrades. 

The cellular alliance features 
McCaw Cellular Communications, 
Contel Cellular, CTE Mobilnet (for- 
merly known as CTE Mobile Com- 
munications), PacTel Cellular, and 
Southwestern Bell Mobile Systems, 
all competitors in the cellular indus- 



try. These firms enlisted fifty additional 
carriers to help UPS extend its immedi- 
ate tracking network across the United 
States. 

Comprehensive Tracking 

The mobile data service is the founda- 
tion for the company's comprehensive 
tracking system— UPS TotaTTrack. which 
provides immediate delivery information 
on bar coded air and ground packages. 
This information was not previously 
available until the day after delivery. 

UPS is the only parcel delivery com- 
pany able to digitally capture both pack- 
age information and the customer's sig- 
nature through a custom-built hand held 
computer called the DIAD (Delivery In- 
formation Acquisition Device). Access to 
the cellular system is activated when the 
UPS driver inserts the DIAD into the ve- 
hicle's unique transmitter (DIAD Vehi- 
cle Adapter). From there, the tracking 
information is uploaded through the cel- 
lular system and UPSnet to the UPS Data 
Center in Newjersey. The invehide • 
equipment and logistical support came 
from Motorola, Inc. with installation by 
UPS's automotive mechanics. 



This cellular network pro- 
vides the connection between 
UPS vehicles and the UPSnet. 
These systems are created to be 
fail-safe with cellular redundan- 
cies, dual access to UPSnet, and 
multiple connections to the data 
system. 

The cellular-based wireless 
data service provides immediate 
access to delivery information for 
more than 1 million UPS daily 
pickup customers. It also provides 
more extensive geographic cover- 
age than any mobile communica- 
tion alternative. 

The UPS mobile data system 
includes several technical innova- 
tions designed to adapt the voice- 
oriented cellular systems for data 
transmission. Error-correction com- 
munication protocols are used to 
ensure error-free message delivery. 
And cellular carriers' switching sys- 
tems are directly connected to UP- 
Snet to reduce the duration and 
cost of data calls. The carriers also 
developed a billing system consoli- 
dating all carrier charges into a sin- 
gle UPS bill and 
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published a unified carrier help desk that 
resolves service problems quickly. 

With the ceUular communications 
technology, UPS TotalTrack can provide 
detailed information on such thing? as 
pickup date, scheduled date of delivery 
status of package, same day verification of 
delivery, and the name of the person who 
received the package, h is available bv call- 
ing a toD*ee Tracking Hot Line (1-600- 
457-4022) which is staffed twenty-four 
hours a day. seven days a week. 

New levels of Service 



In addition to providing customers with 
immediate tracking information. LPS is 
able to provide customers with 
MaxiShip, a PCbased automated 
shipping system designed for cus- 
tomers with high package volume 
and the need for fast package pro- 
cessing. Using UPSprcmded soft- 
ware, the system automatically 
rates and zones packages, prepares 
packages requiring special services, 
such as CO.D. and Delivery Con- 
firmation, and creates user^efiried 
management reports. 

LPS has also created a new 
level of sen-ice that provides guar- 
anteed three-day delivery and im- 
mediate package tracking. Called 
UPS 3 Day Select, it is the first service of its 
kind to be offered in the small package dis- 
tribution industry. UPS 3 Day Select was 
do-eloped primarily for longcr^distance 
shippers who need time^efinite delivery 
and higher levels of information. The ser- 
vice b available to anv shipper for interstate 
delivery throughout the 48 contiguous 
states and is priced between the company's 
tradioonaJ ground and air express services. 

LPS 3 Day Select can be used when a 
long distance shipment must be delivered 
fester than regular LPS ground service. 
Customers are provided with special De- 
coded labels, each with a unique number 
that is scanned into the tracking svstem at 
key points during transit For immediate 
updates on a shipment's status, customers 
can call the Tracking Hot Une and pro 
vide LPS with the tracking number. 

The cellular system developed by 
LPS is considered the most comprehen- 
sive wireless data transmission architecture 



available today. It covers more area and is 
more reliable than any other type of mo- 
bile communication. 

Technology has also provided LTS 
key platforms for expanding its customer 
services globally. In ] 9 88 UPS moved into 
the overseas market with its global elec- 
tronic data communications network, LT- 
Snet. to serve as the information process- 
ing pipeline for international package 
processing and delivery. UPSnet now has 
more than 500,000 miles of lines and links 
more than 1,300 UPS distribution sites in 
forty-six countries. LPS is leasing excess 
lines through a UPS owned company, 
UPS Telecommunications. 

In 1991 LPS's International Ship- 
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mem Processing System (ISPS) received 
the COMPUTIRWORLD/Smiihsonan 
award for innovation in information tech- 
nology. 

Smart Scanning 

Since 1989, ISPS has acquired a universal 
accounong system and an enhanced 
tracking system that can follow the move- 
ment of a package in transit Everv inter- 
naoonal package now undergoes '"smart 
scanning* which takes tracking to the 
next step by determining through bar 
codc technology not only where the pack- 
age « supposed to be. but where it actual- 
ly is. The system also provides for re-rout- 
ing of packages and notifies interim and 
final UPS destinations if a package is ear- 
Jy. late, or routed to the wrong destina- 
tion. 

UPS has long been interested in Elec- 
tronic Data Interchange (EDI), the com- 



puter-to<omputer exchange of in/orma- 
oon. The company has the most extensive 
EDI interaction with foreign customs 
clearance houses in the world, with stan- 
cWd-based systems in place or being devel- 
oped in more than twenty countries EDI 
« allowing UPS to streamline procedures 

eliminate papered censer time and ' 
money. UPS is now able to electronically 
disseminate clearance and delivery infor- 
maoon from the customer's computer, to 
the destination customs agency, to the ' 
consignee. To support these technology 
systems the LPS maintains two data cen- 
ters, in Mahwah and Paramus. New Jersey. 

IPS is not only a global delivery net- 
work, but a telecommunications company 
with its own fiberoptic network and 
its own communications satellite. 
Because of its recent interest in us- 
ing high technology to deliver pack- 
ages, it is easy to forget that the com- 
pany was founded in 1907 in Seattle. 
Now headquartered in Atlanta, LTS 
has more than 273,000 employees, 
delivers 1 1 5 million parcels and 
documents per day, owns ] 16,000 
vehicles and 197 jet aircraft Its ser- 
vice area includes more than 185 
countries and territories, has a daily 
customer base of 1.2 million ship- 
pers, and last year earned $16.5 bil- 
lion in revenues. 
LTS has 3,000 employees involved 
just in technology, owns six mainframe 
computers, 250 minicomputers, and 
41300 PCs compan ywide. It also has 600 
LANs and 18.000 connected workstations, 
100 packet switching nodes worldwide 
and 465.000 miles of dedicated cable cir- 
cuitry. 

LTS's creation of Tota/Track is seen 
both as a major advance in development 
of the cellular industry and encourage- 
mem for the industry itself to undertake 
other advances in data services. 

Tne United Parcel Service is in the 
package distribution business and also the 
information business reporting on its 
package business. The ads that UPS is run- 
ning on oehaif of TotalTrack state that 
"now there's just one thing that travels 
faster than a UPS package. And that's 
news of ic'A happy, and competitive, state 
of affairs. 
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Customer Service Agreement 

You, the Customer, and PC Foods mutally agree to be bound by 

following terms and conditions: 




PC Foods agrees to receive your order, purchase only items 
listed, and deliver them to your designated place of delivery 
within two hours of the time you list on your order as the 
preferred delivery time. This two hour window is the delivery 
time frame. 

All orders received by midnight (est) will be delivered the next 
day within the delivery time frame unless an alternate delivery 
date is specifically requested. Requests for same day delivery 
will be accommodated in most circumstances for an additional 
fee. 

The Customer agrees to be liable for the cost of groceries and 
service fees for the items requested and futher agrees to make 
full payment at the time of delivery. This payment includes the 
grocery total and applicable service fees. PC Foods will accept 
cash, credit card (Visa, Master Card, American Express), 
money orders, or personal checks. A returned check fee of 
$25 00 will be assessed for all returned checks, regardless of 
reason. In the instance PC Foods receives two returned 
checks, a cash-only basis will be invoked. 

The Customer agrees to be available and accept the grocery 
purchase during the delivery time frame. An non-deliverability 
charge of $10.00 will apply if at the expiration of 20 minutes 
past the delivery time frame you or your designate are not 
available to accept the purchase and render full payment. A 
second delivery will be attempted during the same day at a 
reasonable time determined by PC Foods. PC Foods is not 
liable for the freshness or quality of the order past the delivery 
time frame. Due to the perishable nature of the items being 
delivered, when the Customer is not available to receive the 
groceries on the second delivery attempt, the Customer agrees 
to still be liable for all costs and service fees. 

If the Customer fails to pay at the time of delivery or if the 
customer is not available to receive the delivery, the Customer 



Customer service Agreemeni 



agrees to bear and pay collection fees and legal fees 
reasonably necessary to collect the original principal amount 
due to PC Foods. 

If PC Foods cannot for any reason meet our obligation for your 
individual order, all reasonable efforts will be made to notify 
you prior to delivery and you may elect to cancel the order 
without any assessed service fees. 

In addition to the above stated contract between PC Foods and 
you the customer governing the terms and conditions of 
receiving merchandise, the following conditions apply to the 
use of the Ordering System. The PC Foods grocery ordering 
system is the sole property of PC Foods, Inc. You may use this 
proprietary system only after completing a registration form. All 
logos, slogans, operational characteristics, posted articles, and 
code - including publically available HTML, Text, JavaScript, bit 
maps, and the "look & feel" are copyright of PC Foods, Inc. and 
Walker Consulting. You may not publish, reproduce, reverse 
engineer, copy, or create derivative works of the PC Foods 
Ordering System. 

By clicking on the "I Agree" button the customer agrees to be 
liable for any use of the PC Foods ordering system by or 
through that customers assigned account number. You the 
customer also agree to inedemnify PC Foods for any such use. 
PC Foods may alter any terms of this agreement in its sole 
descretion by giving the customer reasonable notice. The 
customer will be deemed to have accepted such changes 
through continued use of the PC Foods ordering system. The 
customer may terminate this agreement by giving PC Foods 
reasonable notice and agrees to be liable for any charges 
incurred. Finally, the customers agrees to provide truthful and 
accurate information on the registration agreement. Failure to 
do so will lead to the termination of your account and possible 
legal action for violation of these agreement terms. 

HAVING READ AND UNDERSTOOD IN FULL THE 
FOREGOING REGISTRATION & CUSTOMER SERVICE 
AGREEMENT, CONTINUE WITH THE REGISTRATION 
PROCESS BY CLICKING ON Start Registration IN THE LEFT 
FRAME. YOU WILL BE ASK TO SIGNIFY YOUR 
AGREEMENT WITH THESE TERMS BY SELECTING / 
AGREE AFTER FILLING OUT THE REGISTRATION FORM. 
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II. DTD PARCEL DELIVERY 

the total industry, including Post umc 
Jenvered about 1.53 billion parcels annually. 
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In the United States where the business started 10 
years earlier than in Japan, companies such as United 
Parcel Service (UPS). DHL, and Federal Express carry 
more than three billion parcels annually. They 
expanded their business world-wide and share now 
more than 60% of Japan's international parcel volume. 
YTC started a joint venture with UPS, DHL founded 
DHL Japan with support from Japan Airline and 
Lufthansa, and Federal Express bought a Japanese 
transport company. 

U.S. DTD - Parcels are picked up by truck and 
delivered to the local hub close to the airport. A hub is 
basically a truck terminal with a high speed sorting 
machine. Parcels which are to be delivered over long 
distances, are flown to Super Hubs via company plane. 
UPS has its Super. Hub in Louisville, KY, and Federal 
Express in Memphis. TN. The last parcels arrive 
around midnight. All the sorting is done in a few 
hours. The parcels are then flown to their destination 
hub, to be picked up by trucks and delivered early in 
the morning. This system is called Hub and Spokes. 



Hub and Spokes 
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figure 4 Figure 5 

According to business reports from UPS and 
Federal Express, their air fleet consists of more than 
300 large body planes. Both companies Super Hubs 
are in the central part of the U.S., and the time zones 
are used effectively. The dynamic super hub system 
has been very successfully implemented. 

Japan's land area is 380,000 square kilometers 
(146,000 square miles), which equates to be 1/25 of 
the U.S.. Japan has four main islands and over 4,000 
smaller islands. The boomerang shaped archipelago 
stretches 2.800 kilometers from north to the south-west. 
The majority of the population lives in the densely 
populated metropolitan areas of Tokyo and Osaka, 
barely 500 kilometers (312 miles) apart. Between these 
two cities the parcel volume is extremely high. On the 



other hand, the parcel volume fo'r the spars* 
populated poles of the country is very low. * ^ 

Due to Japan's unique geographic ai 
demographic features, the american Hub and Spo 
system with its heavy reliance on cargo planes cot 
not be implemented and thus a considerably differ 
DTD derived. 

In 1991, according to Japan's Distribute 
Statistics, the total weight of parcels delivered 
domestic transportation was 6.3 billion tons. T 
trucks share is 5.7 billion tons or 90%. Multiplying t 
weights by the delivery distances, trucks account 
more than 50% weight-distance. Maritime and ■ 
transportation accounts for almost all other pan 
cargo movement, air cargo accounts for less than 1°/ 

Japan has 5,000 kilometers (3.125 miles) 
expressways, covering the country. Tunnels a 
bridges for rails and expressways connect Honshu w 
Hokkaido. Shikoku, and Kyushu. The excellent ro 
and track infrastructure is capable of handling lar 
volumes of cargo. YTC's transportation system tak 
advantage of this by utilizing 11 -15 ton trucks 
ensure fast parcel delivery. The most striki 
difference between the U.S. counterparts, is the vim 
aversion of planes. YTC has a hub in every large ci 
a total of 64. Most hubs have 63 truck routes to 
other hubs. One circum-route provides additibi 
support. In Japan, this system is. called rosenbin. T 
actual rosenbin truck routes exceed 2.200. 
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Figure 7 

Around midnight rosenbin trucks leave for i 
destination hubs where they arrive in the early mornii 
To increase efficiency the truck routes are support 
with airplanes, trains and piggybacks. Sorting is dc 
in a few hours and morning delivery starts. Each r 
sized hub supports 20 to 25 pickup and deliv 
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The first ten yea* QTD regu(a t.ons 

hampered by red tape, no p ^ £jty {of 
we re enacted, and YTC had PPY evef 
an array of permrts. ine " Government acted, 

and finally in 1989. ^J^Sed to revise their 
The Ministry of Transport °^ ea After a lon g 

business friendly regulations. ^ g ^ kjn(j 

The U-S. showed us the p ^ 
.of parcel del-very bus.ness "J tor everybody, 
delivery, flat rate, and equal sen, rf {o 

anywhere. ^^^JJ?. U.S. success 

rs^ 5 dtd ,ndustry " onv 

surpassed by the U.S.. 

HI TAKKYUBIN CUSTOM TRUCK 

VTC started as a ^^"pSTK 
Takkyubin cW^J^^^"^^ parcel 
business and regular trucks we ^ ning . A 

delivery. In ^9^9 °neu«dert chang 
picture showing a brown UPS ^"very a 



H^ion" Inspired by their 
ness. safety and -human vehicle Service 
concept, the manager of YK, v . ^ parts and 
Center, built a prototype using * ^es. Our 
presented it to Yamatos truck m Toyota Motor 

concept was -^T^^^S^ » build fWe 
Corporation approached YTC ana ^ ^ 

prototypes of a TaWcy^b<n »uck. ^ ^ high 
Takkyubin truck was del W ered- ToyQta 
about 60,000.000 yen 4 f-^ fketi na med it "Walk 
realizing the potent* I of a new mar ^ ^ Jhe 
Trough Truck" and added .1 .ten P n {rom 

truck allowed the dr,ver to walk in p a ^ ^ many 
the cabin to the cargo area, i • truCk design, 

critics. A raw and sometimes annoy ^ ^ ^ 
combined with ™F^jS£ 9 team spirit faced 
start. However ^•TjJjSL. by P^iem over 
the challenge and el,m '" ate ^ n P truck production <s now 
the years. Annua. Jfg»"££*C purchased, 
around 1.000. 0u °7 p 2 a °° r Japan. 
9.450 are currently -n use a »°£ r ^ me driver s 
The "Walk Through Trw* co The truck „ 

cabin with the cargo area .nto one ^ ne 
supplied with a high tech. tow e . cargo 

to meet tough ^iss.on con uoM e g ^ ^ 
capacity is two tons and d seats tw h ^ ^ 

allows one to walk <n ^J^ ^ ^ d oor 
cabin to the cargo area, and ear a , fl 
Sn be conveniently opened I from <™J ectiveness and 
accordance wfth the concept 2Q 
Safety. Toyota and YTC transp ortat.on 
every ye a r . ^panese automo b hampef tn 

regulation are very stnct ai nu Every truck must 
freedom on how to bu.ld the ^ruck. ^ The 
pass a very stringent annua. P existing 
Inspections add to *• ^l*^ and YTC have 
trucks. Naturally P e °P ,e t ^ b ,° y a nd transportat.cn 
been struggling with ajomrf* ^ an ascjnated b y the 
agencies since the very beg.nn.ng ^ has 

American UPS truck. relymQ on ^p ^ q( 
improved the veh.cle °ue * in truc k is no match 

companies. ^. , ^ 1nrlu de 3,000 rosenbir 

P YTC's 21.200 veh,c.es . C ^ en W of whid 
trucks and from the 7.000 ^ e ry active rQ{ 

9 450 are Takkyubin trucks. YTC tak ^ ^ 

using their know-how and e ;P er vehicles . 
manufactures of trucks ; to b. d better ^ ^ 

20yearsago.whenl v.s.tea ^ the uP . 

rr r; s ^ d *- ,he 

excellence. 
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Takkyubin Truck 

(wSk Through Truck) manufactured by Toyota. 

SPECIFICATIONS 1991 MODEL (TOYOTA MOTOR 
CORPORATION) 



DIMENSIONS (M) 


LENGTH 5.02 WIDTH 1.79 HEIGHT 2.9 


CLEARANCE 


O.BS H 


CARGO AREA (H) 


LENGTH 2.80 VJlOTH 1.60 HEIGHT 1.74 


CAPACITY WT . 


2 TONS 


CAPACITY VOL 


7.79 CUB. M 


ENGINE 


2.977 CCM 


WHEELBASE 


2.50 M 


TURNING RADIUS 


4.60 M 


TIRES 


FRONT 195-14-6 REAR 185-14-8 






d 



-a 



3 



<33E~Z CESS 
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IV.. DTD INFORMATION SYSTEM 

•Kuroneko Yamato Takkyubin" is the name of our 
"door to door delivery service. It operates from 8 a.m. 
to 8 p.m.. 365 days of the year. The popular saying 
■Call Yamato for a pickup today, to deliver tomorrow, 
is used all over Japan to request Takkyubin serv.ce. 
We provide next day delivery to 99% of Japan. This 
service is controlled by a state of the art computer 

netW ?very driver has a handheld computer (POS). 
Several phases of the parcel delivery are entered into 
the POS- the pickup, the arrival at the originating hub 
the completion of sorting at the destination hub and 
the final delivery. This allows YTC to locate any parcel 

Information is entered by the driver with his 
portable POS and is transmitted by a tele- 
communication network. Passing through the YTC 
sales offices* WS (work station) to the hub s mini 
computers, the data feeds into the mainframe 
computers in Tokyo and Osaka 

The database in the mainframes are updated 
every 15 minutes. Parcel tracking for customer service 
is possible from 8 a.m. to 10 p.m. YTC 
Parcel Inquiry Service.' The parcel's ID number. wh,ch 
is supplied on the invoice as an bar code, allows 
instant parcel tracking. 



Parcel Inquiry Screen 



Off. Arrt«. Cont.KO 
t,.clt*-» $!.««• »•» t- * — 

u.< co»t . 07/17 mn*> «»x»i M «>" 



I I I t T I) I 



TMCIIIlt 



JC«f E» 

tfi^nt Caoloyee H«dtr 



* 



fCO 07/l« 30-19 

jim wo ewia 



09 s«* 



0**215 



52 MW 



J21M1 



Figure 9 

Anv of YTC's truck drivers or 1.600 offices offer 
the customer instant parcel tracking. Customer serv.ce 

"52 System Development (YSD). to which I 
belong is YTC Group's pivot computer company which 

dlS all YTC Group's communication 
information systems. YSD has ^ 
frame computers. These powerful computers are 
Sed^okyo and Osaka and are the backbone for 
SiTmaSg^ and information wn»^ 
networks In case of an emergency. Tokyo and Osaka 
ce^fmutually maintain real-time backups. 24 hours. 



Ihit U.< Tr«sPort.tio«i Sme. or Box Palette CoiuiMf 



Gisioser Oalabaae 



Telephone Operalioi 
Center 




Carry 8«* U9 ° n 



Parcel loduines 
Information 



Figure 10 



NEKO' ON-LINE SYSTEM 
Parcel Tr.duot Sum of KURQNWO Wki*}-^ 

Service Level Chech Sy*l« of T.kkyut-io Information 

V_ ' 
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Parcel Unusual 




Information 




Figure 12 



365 days per year. Main networks have relay points all 
ever Japan, using double NTT (Nippon Telegraph and 
Telephone) and NCC (New Common Carr.er) high- 
speed digital circuits. Each line has at least one 
backup line. Every relay point, is connected with over 
1 600 centers, total communication line length is more 
than 242,000 kilometers (151,000 miles) 

In 1982 YSD's Value Added Network (VAN) 
service was the first to be certified by the Ministry of 
international Trade and Industry for public use. Today 
the system supports YTC and over 180 . customers wrth 
over 13.000 terminals. In 1990. YSD installed a 
international Leased Line (High-speed digital circuit) 
from Tokyo to Los Angeles to start overseas network 

'^Recently. Matsushita (Panasonic) asked YSD to 
operate Electronic Data Interchange (EDI), so the trend 

is from VAN to EDI. . 

Today Yamato System Development is 19 years 
old has a capital of 1.8 billion yen. and 1.100 
employees. YS0 also provides services outs.de of 
YTC In 1991 65% of all sales income, wh.ch was 18.8 
billion yen. was generated from outside customers. 



P ro ,its were a sound 1, b^Y^^^ 
system engineers in our development K 
YSD has its own delivery bus.ness. Our e.gnt 
distribution centers (warehouses), approved by The 
Ministry of Transport, have total ^^'1J^ 
kilometers (9.0 square miles). Approximately 30 trucks 
support the Distribution Operation Centers. 




Figure 14 




Figure 13 
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YSD SYSTEMS 



1. Transportation Information Systems 

1 MCA Delivery Support Systems 

- Pickup Control System • Dispatch Management 

- Delivery Control System - Under Development 

- Driver Control System 

2 Hub Control Systems 

- Automated Sorting System 

- Unit Load System 

3 Digital Driving Pattern Monitors 

- Report Generator 

• Speed. Idle. Rpm. Weight tracking 

- Fleet Management System 

2. Delivery Monitoring Systems 

1 Delivery Status Monitoring System 

2 Delivery Volume Monitoring System 

3. Customer Information Systems 

1 Pre-Print Invoice System (Volume Customer) 

2 Customer Information System 

3 YSD Customized Systems by Business Types 

- Database Package for Home Business 

- Database Package for Mail Order Business 

- Charges Collect Support System 

4. Special Takkyubin Systems 

1 Cool Takkyubin Support System 

2 Book Takkyubin Support System 

3 Food Takkyubin Support System 

4 Time Takkyubin Support System 

5 Leisure Takkyubin Support System 
(Ski. Golf. Luggage) 

5. Application Software 

1 Accounting Packages 

2 Personal Resources Management Systems 

3 Business Management Systems 




Figure 16 




.Nina | Or 



Figure 15 
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y. TRUCK INFORMATION SYSTEMS 

« A *vamoles of YTC's Information 
Below are some examples 01 i 

technology in relation with Takkyubtn trucks. 



1. PICKUP WITH MCA 



is a two way 



Mutti Channel Access (MCA) 

agency. T-Mqjuhn J P£ offe are discounted at 
lor their agenc.es Parc *J ^ must pr0 vide 

,00 yen per parcel. In urban areas YTC m P^ ^ 
superior pickup response for *J er JJJ sefvices . 

„,o» ra ndum. Afl« -ece» 9 ^ ^ 



Prmrs haDoened because extensive customer 
SSS«Kffi to be written down for each new 

Seen the busiest hours of 4 to 6 p£ 
h„H to out customer on hold. MCA 

inefficient. 

. thocp i hree problems Yamato had 



(D 



(2) 



(3) 



(1) 



(2) 



liw time of telephone conversation with the 

t ru cK y Cosest to the pickup locjon and MCA 
transmits the informer, to the ttudL 
Each truck is equipped wrth an 



confer an. can «*• *« P'^^LiS 
up-to-date information can be P e T"\° 

o!U *»" (LOW " ^Xmato 
,4) «t.t pickup tn. dove, enters ™ cMorml 

SSI iSTSfJiS ve«. Mon«oH„ g 

entry errors. 



Pickup Order System 



HCA Sadifl Sriitft 
(MOTOROLA) 




aoDy 



p-cl-Ui Order E»trf T*f»i«j» 




f/gure 17 




figure 18 
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MCA SYSTEM SPECIFICATIONS 
BASE STATION 



0) 
(2) 
(3) 
(4) 
(5) 
(6) 



Motorola (800MHz) MCA SYSTEM 

Fujitsu minicomputer 

Fujitsu FMR personal computers 

Telephone operator Work stations (WS) 16 max. 

UNIX operating system and LAN 

One Fujitsu minicomputer connects with three 

Motorola MCA. 



SYSTEM CAPACITY 

(1) 1 ,000 Takkyubin trucks 

(2) 20,000 customers (Upgrade to 200.000) 

(3) 10,000 pickups a day 

(4) Advanced pickup scheduling, 10 per customer, 
1 ,000 a day, up to 3 months advanced notice 

(5) 10,000 district names to simplify address entry 
(Upgrade to 200,000) 

(6) Reports: Operator performance, MCA usage etc. 

YTC added the MCA radio communication 
system and the customer databases to improve pickup 
service. The system combined with our drivers mission 
to serve the customer best, gives YTC a leading edge 
over the competition. 

Base stations are in every major city and business 
areas. Each base station is surrounded by order 
stations (telephone operation centers). These stations 
support over 9,000 Takkyubin trucks. 

2. ROSENBIN CONTROL SYSTEM 

Parcels are collected by Takkyubin trucks and 
transported to the local hub. From there YTC's 



rosenbin trucks transport the parcels to' the destinatio 
hub. The Rosenbin Control^ System supports, th 
process. 

Every hub has a schedule board similar to th 
departure and arrival boards in airports. This boar 
informs drivers and other employees to facilitate the 
work. 

. The number of hubs has steadily increase) 
reaching 64. in August 1992. Rosenbin trucks ha\ 
about 2,000 scheduled routes per day (See figure 2 
During the holiday season additional support routes a 
added, totaling over 6,000 a day. 

YTC's supervisor used to write standard scheduU 
forever/ route. Changes in parcel volume and truck • 
driver availability forced the rewriting of the schedule 
The schedules were then handed to the truck drivers. 

Today the supervisor obtains his schedules from 
PC. He only enters the driver's name and trui 
number. The truck driver enters the number 
containers and additional cargo information. All data 
transferred to update the databases and the Rosent 
Control System's mainframe. 

The above pre-alert information is used by tl 
destination hub to prepare for arriving truck shipment 

Every truck sends a constant identification sign; 
which is received by electronic check points along tl 
roads. The truck location is then transmitted to tl 
system. In addition the system allows voi- 
communication between trucks and hubs. 

The purpose of this system 

(1) Advise truck driver of traffic jams, accidents ai 
give alternate routes 

(2) Provide anticipated delivery time for customer 

(3) Give pre-alert information to destination hub 



^QC Center 
(/Pick-HP 




f'Ul-ue Cer.ier 



CEDO 



=£fie 



Radio Base 



A'2id i« hit 



3, 



p ; ,i. lP Ncl-o T»tek | 
r,cl ,P Cm* T<f L 



fui;«i , ^ ?ui:«i 
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■ a But 



Ct«i»r 



Figure 19 
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Host CaMiitr 

V*h!(li |nf or*t 1 loo C«rtt»f 



(3) 
(*) 

(5) 



.The information provided includes 
location) 

Utest road and weather reports 

Telecommunication ^ » »PP develop tnis system, 
frequencies throughout Japan » ^ t<j 

Approved frequencies a« 382 ^ ^ ^ ^ 
base communications ana « tember 19 91. a 
truck commumca uons^ ^ tQ g ^ 

Japanese consortium It first satellite based 
for traffic .c° nt «* J , be in operatton in spring 
communication network wm oe k 

1993, . « to use the satellite network in the 

YTC has planes to use tne ^ 
Mure. The system w.H be able g*. ^ g 

ZhT managed by the Pentagon. 



ROSEN8IN SYSTEM SPECIFICATIONS 



(D 
(2) 



(3) 



(4) 
(5) 



(6) 
(7) 



RADIO BASE 




Voice 




File 





Frequency Band 400 MHz / 
Communication Method 

- Dual frequency 
. Semi-duplex operation 

Transmission Power 

- Base 10W 

- Truck 10W 
1 000 trucks capacity 
Transmission activation 

Consecutive tor base 
On demand for truck 
Baud rate is 1,200 bps 
Modulator Method 
MSK 1^00 H2± 100 
Space Frequency band 1,800 - iu 

3 . DIGITAL DRIVING PATTERN MONITORS 

anri transportation department's 
Following police an ^^' Cl^q analog monitors to 
guidelines. YTC has been us.ng a ^ feeen 

record truck driung dig ^l monitors, 

replaced with a new '9™^ ^etl and weight 

management information peeled with the 

The analog monrtors were noi c° 

Advantages of a digital monitors 
(3) Assists driver 

. truck the driver must insert 
To be able to start the ™* me fc The 

his own IC memory cart I *o ^e *g ^ ^ 

recorded informat.on transfers froff M ^ 
POS every 0.5 second^ Th- data ^ 

overall fleet performance, 
information from digital monitors are 

Driver name, departure and arrival times 
Fuel and oil consumption ^ tjme< 

Operation hours, distance ua 
speed, length of stops, etc. 



(1) 
<2> 
(3) 



Figure 20 
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DIGITAL TACHOGRAPHY SAFETY MANAGEMENT 




z * 


Ho 9 t 
Cooipu t e r 




Database 









Headquarters (Safety Do.) 



• Priol Out tanlai 8epart 
of Acctdeat 

• Aai J Tie tbe data froa 
loltUlisi Xicbiec 

Portable 

Persoail Ctmvitr 

for Analysis • Dnpl«y tbe ruilt br 
charts, srapba. aad so 

M 



• Other Data Aulrse for 
Safety Uaaeieaeat 



Ptrsoaal 
Coaputer for 
Analysis 

I I 




YAMATO NETWORK 



IC Card 



tecofoize person plZl} 
theo e&iiae p — [ ' 




Per wail 
iter for 

Analysis 




Brtacfa off let. factorr. aad so oa. 



loltlillxe Xacftloe 



• Preiiht Factory 
Set as iaitial tie 



— Portable 

Persoaal Coopoter 
for ualixe 

0 Wbco accident occurs. Digital 
Tacbofrasb's alert signal (ran&miu 

33 Safeli Maaater- r*r i«t o«i tbe tsrDiot 
leoort of Acc ideal. 
(Ifaea over tbe ufely level) 



Silts Office 



Portable P05 
Stalioa 



■orb 

Stalioa 



Prist oat Basioess 8 e port 
Prist oat laratet leport 
. *1 acc Ideal 

Opijczi fa^t transfer) 

Oblc CWbca over tbe ufelT 

level) 



Priol omI Drivini Notes 
tfbea treasfer) 




Figure 21 

VI. TAKKYUBIN TRUCKS FUTURE 

Door to door parcel service is now a stable 
business monopolized by the big three. But there are 
many improvements needed. A serious problem is 
Japan's acute shortage of human resources. Our 
drivers can deliver an average of a 150 parcels per 
day. YTC has a hard time to hire enough drivers to 
keep up with the constantly increasing parcel volume. 
To ease the driver crunch we reduced their working 
hours, but we still have a shortage. For DTD the driver 
is the core and can not be replaced by any technology. 
Faced with these problems we try increase our 
productivity to perfection. Logistic management 
constantly tries to reduce empty cargo space, 
streamline pickups and reduce redeliveries to a 
minimum. Cost reduction, service improvement, and 



speedier delivery are the driving forces. We ha 
found the almighty strategy, superior inform 
systems to support the drivers are needed. 

Individual hardware and software is getting i 
powerful. However, integration of all our syst 
including communication networks and database 
necessary to meet future demands, i.e. a lnfom< 
But we can not afford to forget about the 
important aspect, safety. 

Japan's DTD service has come a long way 2 
its start. With over 1.5 billion parcel delivered anni 
we are a strong and respected industry. To pre 
the best service to our customers, enabled 
success. We will strive to meet our custo; 
demands with total logistic management. 
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Director 

Applications ImprovemenlDeg. 
Yaraato Transport Co., Lift. 

. of Yamau , Transport Co. is 40% and it 

Rw ndy. information network sy^ave sha* ^ wilh 

made imarkab* prog** in * " J ond S* Pelican (Nippon Express 

business. It can be said that the POS sys^ 1**^ 

which reflects the downstream era, is a ryp.cal lj. YamaU) Co . a 

Also, in *e physical discnbuuon bus, « ^ managemcnt sysiem throughout 

^ information is captured at its source » »* ^ ^ 

Tprocuremen, -"^ n X- - - ^ « * *TuTS 
consumption stages, and progress is tang ^gh «s 
mad e through improvements m thoroughgc- ^ y ^ ^ is putung van- 
tag customer services, in quality ^ ^ „ .. Hor ne-Delivery Serv- 
Jpnovemem of work efficiency. « devdop- «- ne ^ market Qnc ^ ^ther, 
mem of new systems and in the devetopmcnt ce Sen nome -delivery serv- 
oTnew businesses. In any case. these ftu» h *£ *J m homc . dftU very service, 
i not stop ^ at *e improvement of^ee^ horn ,de,ivery service, 
ficiency of an individual business, an . « e delivery service, and au- 
seen in logistic physical distnbuuon. they ex- cc»l service. * addl- 
ed „ total sales strategy by the con .stent p« W» h0 me-deliveryserv- 
" li2 auon of information. ™- ^ m^ic, area covers 99.7% of the ru. 
portanceofnetworks. 1 hope I can help you* ^ d ^ ^ 99.9% of the populauon. 
Lersund *e relations^ of items to be deUvered on the 
distribution ^} nf0 ^J y r ^^l next (lay to 91% of the total items. 



dlStnDUUOli oi"± f 

our company's "hcme-delivery-service infor- 
mation network system" in Ms arucle. 

1. General Situation of the Home- 
Delivery Service 



2. Positioning of tbe Information Net- 
work System 



uenv.., - - * filing point of this homeAtiveiy service 

The system can be explained 
Yara » Transpor, Co. to 40.OX employe £ ^ 0((to „ devetop d 
,.500 .Hie., and 20.000 vehicle 1.1-™*. «™ ^ Mles s-ra^y 

« n,uu«, home-delivery terns a * - ^ ,^„ g ^ding (muscle) sc- 
400 million ' SmCS S vito « on ihe bas.s of .he of- 

number of terns handled by *. -» ™° mi £ sys,em of e-ese musdes and 

fcUvety business is 1 billion items, the markel 

^ Hnflrterlv 



bones is controlled by infection (nerves). 
Tr* home-delivery service cannot be earned 
out without an information network system. 



This information can be divided into up 
informaUon and W information. The 

sources of the 'V '^ imalion ^ 
^delivered. T*e important thing is how 
quickly the item information (slip number, 
customer name, type of item, transport sec- 
don. fare, etc.) can be obtained. Tlus istf* 

origin of the PCS concept. On 
uJ ."down" information is feedback of the 
obtained information, and means the utilrza- 
uon of information in a way that confutes to 
customer services, quality control and im- 
provement of efficiency. The "down 
Ltion does not exist without the "up infer- 

mation and the "up" informauon does o 
exist on the assumption of the existence oHhe 

-down" information. The thing to connect the 
« UP " and "down" information is the database. 
The information network is the general term 
for this. 

3. "Up" Information (Collection of 
Package Information) 



delivery is completed (including the bnngmg 
back of gc^). or when abnormal pac^g« 
are found (misdelivery, unknown address 
breakages). In such cases. SDs do 
nothing but scan a slip number (bar code). Afl 
of the data is transmitted to the host computer 
in Tokyo. 



POS (Point Of Sales) in He transport field 
means the point of receiving packages. Pack- 
age informadon taken at this point can- con- 
fute to quality control and customer serv- 
ices. Therefore, our company gives all fe 
sales driver, (SDs) a portable terminal so that 
tey can input data. Of course, the primary 
role of SDs is the collection and delivery o 
goods, but they contribute to the managemen 
of the company by reflecting the viewpoint of 
Ac customers in their area. This means man- 
agement by all members. SDs are not mere y 
doing blind work. They input data when 
pacies are taken out for delivery, when the 



4. Information Network (NEKO Net) 

The following is the route of information 
^smtssion.mdat.coUectedbymeabove 

mentioned SDs is stored 
minals This portable terminal » called a PP 
^FO»Tc«« Thecal 
^connected 0 acked in) u, a WS (workstauon 
in the office when me SD goes out to make a 

deUvery. or when hereon to theoff.ee aft, 
me collection of goods. Then the dau is 
oansmiued to a small computer cluster)^ 
stalled at a key base (usually one place in each 
p^u.tmar.gesmeomce.^a 

public line. The data is automaucally tran - 
miued from the cluster to the host compute in 
Tokyo through a leased line (optical cabled 
Js.all the data is stored database of die 
host computer. Then, it is processed ad d- 
ing to its purposes, changed into "down uv 
Ladon Wle information) ^ an then 
distributed to the necessary locations (See 
Figure 1 & 2). 



5. Database 

Tr,e host'eomputer that takes charge of the 
database is located in Kamiuma. Tokyo. It s 
controlled and o^rated by the Yamato S - 

tems Development Co. This is a 100% m- 
vested subsidiary of the Yamato Transport 
Co.. which was created through making the 
computer section of the Yamato Transport 
Co. independent in 1972. Since then, the 

)in .n rnmmiter Quarterly 



Yamaio Systems Development Co. has under- 
taken not only the important mission of infor- 
mation processing for the Yamato Transport 
Co., it has also responded widely to the de- 
mands of other companies. The data on vari- 
ous goods that is stored in the databases is 
processed according to its use and purpose. 
The company computer is used for on-line op- 
erations from 8:00 am. to 10:30 p.m. and for 
batch processing (fare receivables and related 
billing work, wage calculations, flash reports 
of sales and various statistical operations) 
during the night shift However, as for the 
pursuit of goods" which is described later, 
batch update is performed at 30-mtnutd inter- 
vals in the daytime also for real-time informa- 
tion. By taking the cable fire accident that oc- 
curred in Setagaya in 1984 as a lesson, a 
backup host machine is installed in Osaka. 

6. "Down" Information (Utilization of 
Information) 

Although there are various information us- 
ages, two typical examples will be introduced 
here. 

(1) Package Tracking System 

What is happening to his or her package is the 
customer's greatest concern. Therefore, re- 
plying to this concern is the duty of the trans- 
porter. As described in the section on "up" in- 
formation, package information is stored in 
the host computer, therefore, it can be seen 
immediately when and from where the pack- 
age was sent and what is happening to it now, 
including the delivery process. Although it is 
not easy to search for a certain package from 
a great amount of data, the current computer 
can do it without difficulty. 



(2) Checking Service Level (Control or 
the number of transport days) 

What attracts people to the home delivery 
service is that delivery is made on the next 
day. Breaking a promise is an important issue. 
To check this, each delivered item is watched 
with the computer to see where it was. sent 
from, where it was transported to and in how 
many days, regardless of whether or not a 
complaint was made. The percentage of unde- 
livered items (the percentage of the number of 
items exceeding the specified number of days 
for transport) is calculated for the territories 
with bad delivery performance. The levels of 
performance are distinguished by color, such 
as red and yellow, as an index to improve the 
quality of transportation. This is outputted 
once a month for an ordinary month and out- 
putted every day in December, which is a busy 
month. 

7. Radio System Using the Computer 

There are two radio systems thai connect ve- 
hicles and offices. One is a collection instruc- 
tion system for collection vehicles and the 
other is an operations control information sys- 
tem for operations vehicles. 

(1) Collection instruction system 

The requests from customers for collection of 
items are made by telephone to an office. The 
reception clerk asks for the customer tele- 
phone number and inputs it into the reception 
machine, then data such as customer name, 
address, and telephone number is displayed 
on the screen. This data is automatically 
transmitted to the appropriate vehicle by wire- 
less and is printed on a printer on the driver's 
seaL Consequently, collection activity can be 
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performed immediacy by this system, ena- 
bling just-in-ume response 10 a corners' re- 
quest. 

(2) Operations control information 
system 

TWs is a tracking system for the operations ve- 
hides that mainly travel for long distances at 
nighL Check points (offices) are established 
along tiunk expressways. A special radio- 
wave network is spread over these areas to 
automatically catch the operations vehicles of 
^ company Out pass through. This data is 
automatically reported to the host computer 
and the host computer collates the data with 
the schedule. If there is a delayed vehicle, the 
host computer reports this to the destination 
office so that the work setup can be pread- 
justed (See Figure 3). 

8. New Businesses 



The home delivery service network is in- 
volved in the creation of new businesses. 
Recently, direct marketing sales without a 
store, such as direct sales from areas of pro- 
duction and mail order sales are being devel- 
oped, but they cannot be carried out without 
home delivery service as a consumer-direct- 
connecuon-type system. Therefore, we are 
creating subsidiaries that will provide assis- 
tance services related to customers sales and 
collection of money and information as a 
regular part of business, not as a side business 
to the home delivery service. 

(1) Yamato Collect Service Co., Ltd. 

This is a 100% invested subsidiary of the 
Yamato Transport Co. This company is in 
charge of the cash-on-delivery business of 



home delivery. The payment for goods can be 
collected quickly without errors by append- 
ing the price of the goods to the home delivery 
slip Although it was performed by the major 
transpon companies who called it "cash-on- 
delivery," as it was very troublesome, most of 
the companies tried to avoid it. However 
with the spreading of the information network 
together with the improvement of home deliv- 
ery service, it can now be performed securely, 
quickly and easily. This business is changing 
with good results. 

(2) Yamato Systems Development Co., 
Ltd. 

This company is a 100% invesied subsidiary 
of the Yamato Transport Co.. and manages 
their NEKO system, mentioned above. 
Yamato Systems Development also proves 
computer services to other companies and 
these sales are greater than sales to Yamato 
Transport. This is the first VAN company in 
. Japan and it supports various sales systems 
named Joints, such as telemarketing. POb 
system, collection of payments and agent 
salesman control. The customers need only 
endeavor to use these systems for merchan- 
dise planning and advertisement The packet 
switching network is overlapped on the 
NEKO Net with access points provided 
throughout the country. This system is sold as 
an assistant (connected with home delivery) 
VAN awaiting customers' use (See Figure 4). 



(3) Book Service Co., Ltd. 

This is a joint-investment company with 
Kurita Bookstore for the sales of publica- 
tions, the procurement of ordered publica- 
uons and their delivery throughout the coun- 
try M a publications database is available. 



orders made by postcard, telephone, facsimile 
machine and personal computer can be proc- 
essed through their offices all over the coun- 
try, and then the ordered publications are as- 
sembled and delivered. The collecting system 
of Yamato Collect Service is used for the col- 
lection of money. The cost for delivery of a 
standard-sized box is 300 yen throughout the 
country. 



9. Conclusion 

We arc in a global age. Even if it is night 
where you live, somewhere on the earth it is 
day. Japan can keep an all-night vigil. Devel- 
oping an uninterrupted global computer net- 
work will be even more desirable in the fu- 
ture. 
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METHOD AND SYSTEM FOR CONDUCTING 
ELECTRONIC COMMERCE TRANSACTIONS 

CROSS-REFERENCE TO RELATED APPLICATION 

This application is a continuation-in-part of U.S. Provisional Application No. 
60/054,121, filed July 29, 1997. 

Background 

rinr" tTU|: KVF.NT10N 

This invention Plains in general to electronic commerce and in parUcu.ar to a method 
and system for contacting electronic payment transactions via the Internet. 

p A r^BOl TUP or THF IMVF.NT10N 

Electronic commerce conducted over the Internet has become increasingly tmportant 
over the last decade. Online merchants offer goods and services for sale or rent includmg 
physical objects such as compact disks, books, and clothmg, and intellectual property such as 
streaming mus.c and movies and electronic book, Physical nan. may be delivered to the 
customer via the mail or a variety of other shipping options. Intellectual property, m contrast, 
m aybede,iveredtothecu^^ 

("FTP"), Proving the customer whh an access key, establishing a telnet session, or through 
some other form of electronic delivery. 

Typically, these goods and services are displayed on the merchant's web sue and a 
pr0 s P ecuve customer view* se.ects, a.d purchases the goods using web browsing software 
Lh as NETSCAPE NAVIGATOR*. The customer usually pays for a product by estabhshmg 
a secure connection with the merchant's web server and transmitting payment mformauon, 
SU chasacreditcard number, to the merchant. The merchant then uses back-end processmg to 
verify the payment information and receive payment. For example, the merchant may use a 
secure telephone line or network link to contact the credit card issuer before acceptmg the 
customer's order. Eventually, the merchant and credh card issuer settle payment and the 
merchant delivers the product or service to the customer. 

A difficulty with the above-described scenario is that each merchant must rmplement 
inventoryandpaymentdatabaseandapaymentacceptanceandverificationsyste^ For 
example, the merchant must establish and maintain a database tracking sales, dehvery, and 
parent information and product inventories in order to support the electronic commerce 
JL There ,s significant cost and complexity in maintaining this database, mcludmg the 
5 La* of integrating it with legacy accounting and fulfillment systems and aggravated by 
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the scarcity of truly skilled personnel. In addition, the merchant must design web pages to 
securely accept the order and payment information and implement the functionality to verify * 
the payment. These tasks can be extremely difficult if the merchant accepts payment using 
many different methods, such as credit cards and electronic fund transfers, or accepts payment 

5 in more than one currency. Moreover, having a large number of separate payment acceptance 
systems on the Internet provides a greater opportunity for fraud and abuse because the flaws of 
each system can be exploited. 

Although Internet-based electronic commerce clearinghouses have been developed to 
handle transactions from many different parties, these clearinghouses do not provide a 

10 convenient interface to the merchant. In addition, the merchant must still establish the 
payment, verification, and database systems described above. 

Accordingly, there is a need in the art for a method and system for conducting 
electronic commerce on the Internet which reduces the amount of work that must be performed 
by the online merchant. Preferably, the method and system will allow the merchant to easily 

15 and verifiably perform inventory, sales, and delivery tracking and transparently support 
different types of payments and currencies. 

Summary of the Invention 

The above needs are met by a method and system for conducting electronic commerce 
20 transactions that allows a merchant to easily sell a mix of physical and intangible items and 

supports sales, inventory, and delivery tracking and a variety of payment systems by having the 
merchant establish an account on a commerce server. The commerce server provides the 
merchant with inventory, accounting, and order management systems. Furthermore, the 
commerce server allows merchants to conduct electronic commerce with other merchants and 
25 vendors. 

The commerce server includes a web server providing web pages to the merchant. By 
using these web pages, the merchant establishes an account on the commerce server. Then, the 
merchant provides the commerce server with information about an item sold by the merchant, 
such as a plane ticket, clothing, a book, a software product, or playing time with an online 
30 game. The merchant also provides the commerce server with other attributes of the item from 
which the customer may select, for example, the quantity or duration of an item. In addition, 
the merchant supplies payment processing rules defining the payment options that are 
acceptable to the merchant, such as which currencies and payment systems are allowed and 
when or how often to bill the customer. 
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The commerce server preferably s,ores <be information receive, from the mercha* m 
m entry ofadatabase. m one embodiment, the da.ab.se entry categoric ft. ..em as a hard 
To 1 or online good depending upon the deliver op.ions avaiUble for me «. 
r—^nl.ion.provides.e — w i,h a W en = ne,nd,„ g a 

,i„n allowing .he commerce server ,0 tde».ify me database entry w.4 wh.ch (he 

uc> .n response, .he cus,om.r-s compu,er is automatical* direced .0 me web 
JiaddLn, me cus.omerispresen.edwi.h.h.paymen. options auowedby me 

with me paymen. information necessary .0 complele .he transaction. 
|5 Z to, -chan,s paymen. «nns specify ,ha, paymen, is retired, me — 

.erverpreferabiyidentif.es.heremo.ep.^n.systemseiectedbymecus.omerandcon.acts,. 

server preleraoiy Vr .,.M y a module within me commerce 

,o comple.. .he eleclronic commerce .ransacuon. Preferably, am 

h« rails .enerated by me commerce server imo .he forma, used by .he selected 
server ™ ^ h m Me converts responses received from .he payment system 

A me.hod of conducting election* — ^™ ^ 
merchant in accordance with the present mvenuon mcludes rece.™g 
„ an item to be purchased by the customer, receiving paymen. mformation spec.fy.ng p J™ 

wrth aremo,epay™e„,sys,emspec,nedbymepayme„, information, andprovmmg me 
corner and .he merchant wim ,hc resul, of me paymen. transaction 

Similarly, compmer program mstructions for conducting electron* commerce 

,0 transactions in accordance wim the present invention include instructions for s.onng ..em 
"l.eceivedfrom.hemerchanur^ctionsforissuingu.emerchan.arefe.nce.o 

Ts^d em information, instructions for receiving an election, commerce tiansaction 
X from ,he cns,omer eon,a,„ing me reference to me s,ored i.em information .ssned ,o 
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the merchant, instructions for accepting payment information from the customer, and 
instructions for conducting the electronic commerce transaction with a remote payment system. 

Brief Description of the Drawings 
5 FIGURE 1 is a high-level block diagram of an electronic commerce system according 

to an embodiment of the present invention; 

FIGURE 2 is a high-level block diagram illustrating functional components of a 
commerce server according to an embodiment of the present invention; 

FIGURE 3 is a high-level block diagram of an entry in a database associated with the 
1 0 commerce server according to an embodiment of the present invention; 

FIGURE 4 is a flow diagram illustrating the interactions between the customer, 
merchant, commerce server, and payment system when completing a payment transaction 
according to an embodiment of the present invention; and 

FIGURE 5 illustrates an exemplary screen display of a web page seeking payment 
1 5 information from a customer; and 

FIGURE 6 illustrates an exemplary screen display of an order confirmation web page. 

Detailed Description of the Preferred Embodiment 

As used herein, the "Internet" refers to the global network of interconnected computer 
20 systems and the "World Wide Web" ("WWW") refers to the global hypertext system using the 
Internet as its transport mechanism. A "universal resource locator" ("URL") is a reference to a 
piece of information or a software function on a computer connected to the Internet. A "web 
server" is a program that accepts requests for information framed according to the HyperText 
Transport Protocol ("HTTP"). "Web pages" are the information supplied by the web server in 
25 response to the requests. The Common Gateway Interface ("CGI") is the standard that 

describes how the web server accesses external programs, usually called "CGI programs" or 
"CGI scripts," called by a web page. Of course, the present invention is not limited to the 
Internet and may be used with any digital network supporting electronic commerce. In a non- 
Intemet-based system, the terms defined above also include the non-Internet-based equivalents 
30 for communicating between the various entities described herein. 

FIG. 1 is a high-level block diagram of an electronic commerce system 100 according 
to an embodiment of the present invention. Illustrated are a customer computer (sometimes 
referred to as "the customer") 1 10, a merchant web server (sometimes referred to as "the 
merchant") 112, and a commerce server ("CS") 114, all coupled to the Internet 116. In a 

4 
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typi ca, embodiment, ft. — compter 110b. per— «*« having, among ota 

1 lld «o the interne, ,16 via a network connection 11B . The netwo* _„ may be, for 
example a modem coupled to an analog telephone line, a digital subscriber line, a cable 

Cher communications medium. Web browsing software, such as NETSCAPE 
NAVIGATOR* preferably executes on the client computer and sends data from the chert 
compute, 1.0 to the merchant web server 1 12 via the network connection 1 1 8 and Interne. 
„ 6 ,„ another embodiment, the customer computer 1 10 is a pa.m-.op device or personal 
digit a, system communicating vi, radio waves wi,h .he ln,eme. 1,6 or another e,ecromc 

commerce system. wen t 
The merchan, web server 1 12 is preferably similar .0 .he customer computer 1 10 except 

,ha, i, is has the processing power and communications 1 . 6 bandwidth ,0 handle multtple 
simu.taneous customer transactions. Themerchan. 1.2 sens items, such as merchant, 
information, intellect property, and/or services via a web site hosted on the merc^web 
server 1 12 The merchant's . 12 web site may, for example, display a catalog of softwar 
available for purchase, allow ,h. customer 1.0 to view flight schedules and purchase a plane 
^raliovv ,he cus.omerllO.op.ayanon.ineg^.down.oadabooK or mus,c,or access 

a database of information. 

As used herein, me .erms "customer" and "merchant" depend upon the specfic 
taction being conduced, .n a cha,n of commerce transactions, the "customer" ,n a firs, 
rransacnon may be a "merchant" in a second transacon. Fo, example, the customer 10 may 
buy components of .product from severa, d.fferent vendors ormerchants H2 ustngfte 
e,ectronic commerce system described herein and then, in turn, se„ the combmed product v,a 
the customer's own web site and the CS 1 14. 

The merchant's web sit. displays a, .east one "payment button" A payment button s a 
graphic button, a region of a .arger graphic, a text string, or another form ofURLlink wrnch 
Lc»s,omernOmay>ess«byse,ectin g i.wi,ha m ouse,physica.buno„,oro m er,n P u, 

device, In another embodiment, the payment button may beunhzed onanon-lnternef -d 

••pressed" whenever a customer 1 . 0 expresses a desire to purchase an i.em. As desenbed 
b.,ow,.hepaymen, button is pressed by .he cus.omer 1 10 when ,he c«s,omer 1.0 w,shes .o 
purchase andpay for ,„i,emdisp.ayed for sale on the merchant's web si.e. In a prefermd 
mbodunen, every tyne of i.em fo, sale on ,he merchant's web si.e has a separ..e paymen, 
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button. When a customer 1 10 wishes to purchase the product, the 1 10 customer presses the 
product's associated payment button. Then, the customer 1 1 0 is preferably presented with a - 
menu allowing the customer 1 10 to specify attributes, such as quantity or duration, of the items 
that the customer 1 10 wishes to purchase. 
5 In another embodiment, the merchant web site has only one payment button or has only 

one payment button for each class of items for sale. In this embodiment, the customer 1 10 is 
preferably presented with a menu of choices after pressing the payment button. For example, 
the menu of choices may ask the customer 1 10 to identify a specific product or an attribute of a 
product, like colon that the customer 1 10 wishes to purchase. 
1 0 Every payment button has an associated URL that points to information in the CS 114. 

Preferably, a database key that uniquely identifies the merchant 112 and/or item for sale is 
encoded within the URL. When the customer 1 10 presses the payment button, the customer 
1 10 is redirected to a web page provided by the CS 1 14 and specific to the merchant 112 
and/or item. 

15 In one embodiment, the CS 1 14 queries the customer for the quantity or duration of the 

item that the customer 1 10 wishes to purchase and payment information. The CS 1 14 receives 
the customer's responses and conducts the electronic commerce transaction according to 
payment processing rules and delivery options specified by the merchant 1 12, The CS 1 14 
records the transaction in its database and notifies the customer and merchant whether the 

20 transaction was successful. Accordingly, the merchant 112 is relieved of the responsibility of 
conducting the electronic commerce transaction with the customer 1 10. 

FIG. 2 is a high-level block diagram illustrating functional components of the CS 114 
and also illustrating a remote payment system 222 and a remote merchant 223 according to a 
preferred embodiment of the present invention. The CS 1 14 is preferably similar to the 

25 customer 1 1 0 and merchant 1 12 computers, except that the CS 1 14 has enough processing 
power and Internet 1 16 bandwidth to support many simultaneous payment button transactions 
as described herein. The functionality of the CS 1 14 described herein may be performed by 
hardware or software modules within the CS 114. In one embodiment of the present invention, 
the functionality of the CS 1 14 is provided by software applications executing on INTEL x86- 

30 or SUN MICROSYSTEMS SPARC-compatible hardware under control of MICROSOFT 
WINDOWS NT or a derivative of the UNIX operating system, such as SOLARIS 2.5.1. In 
another embodiment of the present invention, the functionality of the CS 1 14 is provided by a 
distributed computing system as described below. 

6 
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The remote pay,™, system 222 is preferably a .hird-party payment gateway o, system. 
The gateway or system is preferably cor.ec.erf to a financial transaction network, which,.„ - 
m typi ea.ly links to compos at banks and other financial institutions for approval and 
setUemen, of elecronic commerce factions. Typical gateways o, systems may tnch.de 
CYBERCASH e-CASH, MONDEX, or SET. While only one payment system 222 ts 
illu s,ra.ed in FIG. 2, the CS 1 14 may be in communication win, many different remote 
payment systems 222, either through , secure ,ink on ,he mteme. ,16 or a dedicated seen™ 
^Each payment system has ,n applications programming interface ("API"). By ustng the 
API, ,he CS 114 communicates wi.h the paymen, system 222 and performs secure and 

verifiable payment transactions. 

The remote merchant 223 is preferably a merehan. selling items vta a web s..e as 
described above. The remo.e merchant 223 may have an account on the CS , 14 or the 
merchant 2^3 may have an interface for selling items similar to the remo.e paymen, system 
222 ,„ general, ft. remo.e merchan. 223 is included in FIG. 2 ,o iliustrate .ha, .he customer s 
, , 0 eleCronic commerce transact performed by ,he CS 1 ,4 may comae, a remo.e paymen. 

system 222 and/or a remote merchant 223. 

TheCS ,14includes»paymentb»..onuansac,ioncngine210wh,eh. S coupl«i.oa 

da,abase2,2andawebserver214.A fi rewa,,2, 6 prefcrab,ysi,sbe W een,hewebs^er2,6 
and ,he M sac,ion engine 210. While ,hese funcuona, componen,s are ,l.usrra.ed . FK3. as 
discrete en,i,ies. ,he CS 1 14 may be executed on . distributed compter system havtng a 

described herein. Forexample, on. embodimentoftheCSlHuses multiple— n 
engines 210 and web seers 2,4 and a single distributed database 2,2, thereby P rov,dtng 
JIty to theCS ,14. Tne number ofweb servers 2,4 and .ransaCion engines 2,0 depends 
„„ the actual system load and the des,re ,0 achieve better performance mroughbalancng, he 

transaction load across the system. 

T hep» y men,bu„o„ t ransac„o„ t ngin.2,Oinc,udesaru,esmodu,e2,8,ha,eon B o,s 

the interactions and flows of informal necessary to complete a paymen. transact™, ut 
addition the paction engine 2.0 preferably includes a Payment Application Programming 
, ntterface ("PAPn module 220 enabling communication between .he CS 114 and the remote 
tCUs222andmerchan B 223. The PAP1 module 220 abstracts die different APIs 
oflh paymen. system 222 and merchan. 223 in.o a single, higher level, PAP, .ha. can 
in ,erface ««„ each of ,he paymen, systems 222 and merchant 223. The ^ne 
2,0 perfomts paymen, uansacdons with a payment system 222 or merchant 223 by maktng 
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calls to the PAPI. The PAPI abstraction module 220 translates these calls into the specific API 
of the payment system 222 or merchant 223 being used for that transaction. The PAPI 
abstraction module 220 also translates data received from the payment system 222 or merchant 
223 into the format utilized by the transaction engine 210. Accordingly, the PAPI abstraction 
5 module 220 allows support for new payment systems 222 and merchants 223 to be added to the 
CS 1 14 by merely creating a new PAPI to payment system or merchant API mapping in the 
PAPI abstraction module 220. 

The payment button store module ("PB store") 224, in combination with the web server 
214, allows a merchant 1 12 to obtain a payment button. The web server 214 is preferably an 

1 0 industry standard web server such as the NETSCAPE ENTERPRISE SERVER or the 

APACHE web server. The web server 214 provides secure communication with the customer 
110 and preferably uses industry standard technologies including HyperText Markup Language 
0*HTML"), and HTTP to deliver information to the customer 110. In addition, the web server 
preferably uses industry standard encryption techniques, including secure HTTP ("S-HTTP") 

15 and the secure sockets layer ("SSL"), to ensure that communications with the customer 1 10 are 
private. The firewall 216 allows only authorized communications between the web server 214 
and the transaction engine 210 and ensures that a malicious user cannot access or corrupt the 
transaction engine 210. 

The PB store 224 allows the merchant to purchase payment buttons and add product 

20 descriptions, merchant configurations, and other information to the database 212. In a 

preferred embodiment of the present invention, the merchant 112 accesses the PB store through 
a web site on the web server 214. The PB store module 224 captures the merchant 1 12 actions 
on the web server 214 and creates the appropriate entries in the database 212. 

In one embodiment of the present invention, the PB store web site describes the 

25 payment button mechanism, the services offered by the payment button vendor, and the costs 
of the services. In addition, the web site preferably has a merchant registration form 226 for 
registering new merchants, a merchant renewal form 228 for renewing merchant registrations, 
and a payment button generation form 230 for issuing payment buttons to registered 
merchants. The forms preferably include CGI programs for performing the functionality 

30 described herein. 

The merchant registration form 226 allows the merchant 1 12 to input information 
identifying the merchant 112 and includes a payment button with which the merchant 1 12 can 
pay a registration fee. After the fee payment is verified, the merchant 1 12 is preferably issued 
a login/password pair and an account with the CS 1 14 through which the merchant 1 12 can 
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access the paymen, bunon generaion form and maintain ft. merchant accoun, SirniMy, 
the merchant renewal fonn 228 preferably includes a paymcn, bunon with which the merchant 

112 can pay a renewal fee. 

The payment button generation form 230 allows the merchant 1 12 to enter «em 
description data, such as item names and descriptions, prices, types, and delivery opttons, and 
payment processing rules, such as supported credit cards, payment systems, and current, In 

describe when payment is required (e.g., the merchant may require billing after 90 days), 
and/or describe the quantity or duration of an item available for a certain pnee. In one 
embodimentofthepresent invention, the merchant 1 1 2 enters the item description data and 
payment processmg rules by uploading a file to web site having the informal m a 
standardized format. 

When entrv of this data is completed the payment button generate form 230 sends 
the data to the transition engine 210, which stores the information in the database 212 at a 
location specified by a key. The transaction engine 210 passes the key back to the PB store 
web site which provides the merchant with a payment button download page d.splaymg the 
res ults of the payment button generation transaction. If the transaction was success*. 1, the 
payment button download page includes the payment button issued to the merchant 1 1 2. 
payment button has an associated URL that specifies the key. Accordingly, little or no 
engineering effort is required to maintain each merchant configurate on the CS 1 14. 

In one embodiment of the present invention, there are multiple PB store web sues 
commumcatine with the database 212 through the transaction engine 210. When a payment 
bu «on is created, the transaction engine 210 creates a field in the database 212 entry specfymg 
the PB store that generated the payment button. Accordingly, payment buttons may be 
i -branded" among different payment button vendors. 

The database 21 2 is preferably a robust relational database. A preferred embodtment of 
the present invention uses the ORACLE 7 database to implement the functionality desenbed 
herein The database 212 stores item descriptions, payment processing rules, and other 
information necessarytocompleteapayment transaction on behalf of a merchant 112. This 
0 merchant informal is preferably accessed in the database by using a key assigned to each 
m erchant 112 and/or item for sale. The database 212 is also used as a repository of transacts 
information including authorization logs, payment status and completion records, and other 
information required by the merchant 1 12 and the CS 1 14. 
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FIG. 3 is a high-level block diagram of functional components within the database 212. 
Illustrated therein are a database entry 300 including a primary entry 310 linked to at least one 
of three types of item entries 312, 314, 316. The primary entry 310 is the entry identified by 
the key provided to the merchant 1 12. Accordingly, the primary entry 310 is typically 
5 accessed either when the merchant 1 1 2 provides the key while using the PB store web site or 
when the customer 1 1 0 uses the URL provided by a payment button to purchase the item 
identified in the database entry 310. 

The primary entry 3 1 0 contains a field 3 1 8 storing the payment processing rules for the 
item as specified by the merchant 1 1 2 through the PB store. The primary entry 310 also 
10 contains a field 320 holding item type information as specified by the merchant 1 12. The item - 
type information preferably describes the item attributes input by the merchant 112. In 
addition, the item type information field 320 preferably contains at least one link to another 
database entry 312, 314, 316 describing delivery options for the item. 

The available delivery options for an item depend upon the type of item. FIG. 3 
1 15 illustrates three database entries 312, 314, 316 describing delivery options for hard, soft, and 
online items. However, an embodiment of the present invention may have many different 
types of items and corresponding delivery options. A hard item is typically a manufactured 
physical product such as clothing, a book, or a machine part. Accordingly, the entry 312 
holding delivery options 322 may list various shipping methods and companies available for 
20 delivering the hard item to the customer 110. 

A soft item, in contrast, is typically intangible intellectual property such as music, 
electronic books, or software. For example, the soft item may be a streaming music file that 
can be played by the customer 1 10. Accordingly, the entry 314 holding delivery options 324 
may list a URL or electronic key that can be provided to the customer to effectuate the 
25 purchase. For example, the options 324 may provide instructions for initiating an FTP session 
to download the purchased soft item to the customer's 1 10 computer system. 

An online item is typically access to an online service or other software executing 
remotely from the customer 1 10. For example, the online item may be access to an electronic 
database of information or an online game. Accordingly, the entry 316 holding delivery 
30 options 326 preferably includes instructions for allowing the customer 1 10 to access the online 
item. For example, the options 326 may provide instructions for initiating a telnet session with 
an electronic database for a limited duration of time. 

FIG. 4 is a flow diagram illustrating the interactions between the customer 110, 
merchant 1 12, CS 1 14, database 212 and a payment system 222 when completing a payment 

10 
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Ins between .he various entities. FIG. 4 il.ustta.es only major mteracttons 
ofthe oresen, i«ven,ion wherein me merchant's U2 payment processtng rules 

^ «any, Ute cus,omer U0 is browsmg ,he merchan,, web si,e ana decides ,0 P«hase 

^tr— ------ *«-- rtt --' , -■ 4,4 

™ 4,6 .he database 2.2 - dynamically • «- » 

Lutes and pavmen. opto available for .he i«em as define* by ,he merchan, 1 12. I. 
^ncVl.P^bly — .el^eu.il^by.ee—,^ 

„,d hv .he merchant 1 12 and modifies the web page accordingly. Thts 
cun-ences supported by the nrcrchan. FIG 5 illustrates an exemplary screen 

e eneratedwebpageissent418lolhecustomerl>0. FIG. Ml. 

» Lay 500 of *e web page seeking paymen, information from the customer 1 ,0. 

' ^ 2 customer selects me desired i.em attributes and payment se^ce enters any 
neJy paymen, in—, such as a credi, card or account number, and ,ransm «0 
necessarypy ^ cs 114 SC0Ie s 422 me received data in the database 212 and 

mese data ,o the CS 1 14. Th CS 1 4 ^ ^ 

contacts the selected paymen, sysiem 222. As descrme 
, 5 PAPlm odule220,o,ra„s,a,e,r,nsae,ionca,,smadebythettansae,,o„e„g,n 2, mtotheAP. 

" J£ se.ec.ed paymen, sys,em 222. TheCS 114 preferably stores 426 records o , 
ommunicauons wi.h ,he paymen, sys,em 222, cus,omer ,10, and merchan, 1 12 - *. 
71 2,2 Therefore to, database 212 can be used to reconstruct transact™ htstones « 

If the paymen. system 222 approves the transacts, the CS dynamtcaUy g 
cus,rer,,O.Thispagepreferab, y c„„^ar«ceip. or conftrmatton number gene^tedby 
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the CS 1 14. In a preferred embodiment of the present invention, the confirmation number is a 
unique number encoding transaction, session, and merchant identifications and a time and date 
stamp. This confirmation number is preferably a key to a database entry holding the 
transaction information and can be used later by the merchant 1 12 and customer 1 10 to confirm 
5 payment, to query the CS 1 14 for payment status information, and to use the CS 1 14 to query 
the payment system for account status information. The web page also preferably contains any 
other information required by the merchant 1 12 and a link to a confirmation page on the 
merchant's web site 1 12. FIG. 6 illustrates an exemplary screen display 600 of an order 
confirmation web page. 

1 0 Tire CS 1 1 4 also notifies 428 the merchant 1 1 2 that payment was accepted and provides 

the same receipt or confirmation number as was provided to the customer 1 10. In one 
embodiment, this notification is performed via a secure electronic mail message. Accordingly, 
both the customer 1 1 0 and merchant 1 1 2 are notified that the purchase was made. 

Finally, the customer 110 fetches 430 the confirmation web page on the merchant's 

15 web site. Preferably, this web page provides the customer 1 10 with additional information 
about the purchase or any other information which the merchant 1 1 2 desires to provide. 

In summary, the present invention is a system, method, and computer program 
instructions for conducting electronic commerce transactions via the Internet or any electronic 
communication system. The merchant 1 12 opens an account on the CS 1 14 and supplies 

20 information about items sold by the merchant 112. The CS 1 14 stores this information in a 
database 212 entry and issues the merchant 112 a URL containing the key to database entry. 
The merchant 1 12 supplies this URL to customers wishing to purchase an item, causing a 
customer 1 10 to be connected to the CS 1 14. The CS 1 14 collects payment information from 
the customer 1 10, conducts the electronic commerce transaction with a remote payment system 

25 222, and notifies the customer 1 1 0 and merchant 1 12 of the result. 
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Claims 

I claim: 

x . A computer system for supporting electron* commerce transactions between a 
customer and a remote merchant, the computer system comprising: 

a database having an entry including merchant information identifying an item 

offered for sale by the remote merchant; and 
a transaction engine in communication with the database and a remote payment 
system for performing an electronic commerce transaction, the transacts 
engine comprising: 

a first module for receiving an electronic commerce transaction identifier 

from the customer, the electronic commerce transaction identifier 

specifying the entry in the database; 
a second module for accepting payment information from the customer, the 

payment information identifying the remote payment system; and 
a third module for performing the electronic commerce transaction with the 

remote payment system using the payment information received 

from the customer. 

2 . The computer system of claim 1 , wherein .he transaction engine further 

COmPnSK: a fourth moouie for „o,if y ,n g the remote merchant and the customer of a resui, of 
the electronic commerce transaction. 

3 The computer system of claim 1 . further comprising: 
' a web server in communication with the transaction engine for communicating with 
the remote merchant and customer; and 
a firewall between the web server and the transaction engine for securing 

communications between the web server and the transaction engine. 

4. The computer system of claim 3, wherein the transaction engine further 
comprises: ^ ^ ^ ^ ^ fa ^ database 



a 



0 



fifth module for dynamically generating a 

and providing the web page to the customer via the web server, the web 
page providing information about the item offered for sale by the remote 
13 
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merchant and facilitating collection of the payment information from the 
customer. 

5. The computer system of claim 3, wherein the computer system further 
comprises: 

a sixth module for accepting the merchant information identifying the item offered 
for sale by the remote merchant via the web server, creating the database 
entry for holding the merchant information, and providing the remote 
merchant with a reference to the database entry. 

6. The computer system of claim 1, wherein the electronic commerce transaction 
identifier is a URL identifying the computer system and including a key to the entry in the 
database. 

7. The computer system of claim 1 , wherein the database further comprises: 

an entry specifying payment processing rules defined by the remote merchant; and 
an entry specifying delivery options for the item offered for sale by the remote 
merchant. 

8. The computer system of claim 1 , wherein there are a plurality of available 
remote payment systems and wherein the second module for accepting payment information 
from the customer accepts payment information identifying one of the available remote 
payment systems. 

9. The computer system of claim 1, wherein the transaction engine is executed by 
a plurality of distributed computer systems. 

10. A method of conducting electronic commerce between a remote customer and a 
remote merchant, the method comprising the steps of: 

receiving information identifying an item to be purchased by the remote customer; 
receiving payment information specifying a payment method to be used by the 

remote customer to purchase the item; 
conducting a payment transaction with a remote payment system specified by the 

payment information; and 

14 
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providing the remote customer and the remote merchant with a result of the 
payment transaction. 

1 1 The method of claim 10, further comprising the steps of: 

' receiving information about the item to be purchased from the remote merchant; 
storing the information about the item to be purchased at a specified location; and 
providing the remote merchant with a reference to the specified location. 

12 The method of claim 1 1 , wherein the remote merchant provides the reference to 
the specified location to the remote customer responsive to the remote customer desiring to 
purchase the item. 

13. The method of claim 1 0, further comprising the step of: 

providing the remote customer with a list of item attributes from which the 
customer can select. 

14. The method of claim 10, wherein the step of receiving information identifying 
the item to be purchased by the remote customer comprises the steps of: 

receiving payment processing rules specifying payment options available for 

purchasing the item; and 
receiving delivery options for the item. 

15 A computer-readable medium having computer instructions encoded thereon for 
conducting electronic commerce transactions between a remote merchant and a remote 
customer, the computer instructions comprising: 

instructions for storing item information received from the remote merchant; 
.nsrructions for issuing the remote merchant a reference to the stored item 
information; 

instructions for receiving an electronic commerce transaction identifier from the 
remote customer containing the reference to the stored item information 
issued to the remote merchant; 

instructions for accepting payment information from the remote customer, the 
payment information identifying a remote payment system; and 
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instructions for conducting the electronic commerce Transaction with the remote 
payment system using the payment information received from the remote * 
customer. 

16. The computer-readable medium of claim 15, wherein the instructions further 
comprise: 

instructions for notifying the remote merchant and the remote customer of a result 
of the electronic commerce transaction. 

1 7. The computer-readable medium of claim 1 5, wherein the instructions for storing 
item information received from the remote merchant comprise: 

instructions for receiving payment processing rules from the remote merchant 

specifying payment options for the electronic commerce transaction; and 

instructions for receiving delivery rules from the remote merchant specifying 
delivery options for the electronic commerce transaction. 



16 



WO 99/07121 



PCT/US98/15884 




WO 99/07121 



PCT/US98/15884 




WO 99/07121 



PCT/US98/15884 




WO 99/07121 



PCT/US98/15884 




WO 99/07121 



PCT/US98/15884 



tMrtadvantaqej Pnvmtt* befall* J 



Please r**tf» tfcto p««e ud emmn 
There .» • Mafc* Ca incniw i' b« 



it !■ 



t'miiut-is Oi tU rtd 



;i'HI?' - Sprocket <M< 



St.99 

S»bt*talt 
SkJppiaf i 
Tmmi 
Totali 



S17.M 

S17-9S 
ST93 
$1.71 

123.41 




ftt I) 



I *a\ iiiunl I nl fliniiuticiii 



i.:,p «. o... /f - :<MM/Ym 



i Md><- « urrpruon\tfrmrpit OrtlrrJ 



5/6 



WO 99/07121 



PCTYUS98/15884 



itetarivantanej H— tot i 



— tiitmh itttt ) «i/r Urtfrr -- 



Receipt Number: 158-8029.5 



Global Sprokets Company Inc. 

2243 £ W j,icnt Way, Boaton. MA. 24248. USA. 
Tel: «v *3« 0377: FAX: ♦! 850 3310318 
mta^ wrakvu.com; Webi httpV'aw 



Plea* pnm or «i*e this pifc and keep • copy in i 
Tm m*» »it« wn wan eua p*jr* ana fwnv n ovnvg ew mu 30 d*yi 
y«*i will »c KQwncfl id enter voir Uit bob 
(m luted bckvw) to CAM 



1*1 iilIik ts I M'llci v<l 



Item ««r gt> ilea* 

215039 2 Sprocket fMadaam) 



tt.99 



S17.9S 



3»lppta t i 

Tui 

Total: 



Sl.f 3 
$L72 
123.45 




(lilliu:* Vtl.ii 



Joe 

Btogfi 

Global Bakine Company 
2233 N PmnfeMD | 



San iotc 
CA 

U6023-3I23 
USA 



" |>lit|ifiitm ..\t(iii % 



litem I ill urination 



Paymvnt r*p«: 

Your varn h»« oe«n cfiarflrd: 



Mastercard 
$23.63 



C'liHiiiiniT- 1 iiiomtul inn 



We aim in into oil items within 10 davi. 
Thank vou f«r .our order) 



[Return to MteJ 



r 



6/6 



I ' VERSION* 



10m 



PCT 



WORLD INTELLECTUAL PROPERTY ORGANIZATION 
International Bureau 



INTERNATIONAL APPLICATI ON PUBLISHED UNDEP T HE PATENT COOPERATION TREATY (PCT) 

llNlDIvnAii^ _ OQ//V71 



(51) Internationa) Patent Classification 6 : 
H04L 25/02 



(21) International Application Number: PCT/US98/ 15884 

(22) International Filing Date: 28 July 1998 (28.07.98) 



A2 



(11) International Publication Number: WO 99/07121 

(43) International Publication Date: 1 1 February 1999 QK02.99) 



(30) Priority Data: 
60/054,121 



29 July 1997 (29.07.97) 



US 



(71) Applicant: NETADVANTAGE CORPORATION [US/US]; 
Suite B, 1674 North Shoreline Boulevard, Mountain View, 
CA 94043-1316 (US). 

(72) Inventor: FETIK, Richard, J.; #4 Comstock Queen Court, 
Mountain View, CA 94043 (US). 

114) Aeents: HOFFMAN, Brian, M. et al.; Fenwick & West LLP, 
( } 8 Two Palo Alto Square, Palo Alto, CA 94306 (US). 



<*1\ Desienated States: AL, AM, AT, AU, AZ. BA, BB, BG, BR, 

GH, GM, HR, HU, ID. IL, IS, JP KE, 1 KG KP KR KZ, 
LC LK, LR. LS, LT, LU, LV, MD, MG, MK, MN MW, 
MX NO, NZ, PL, PT, RO. RU, SD, SE, SG, SI, SK SL, TJ 
TM TR, TT, UA, UG, UZ, VN. YU, ZW, ARIPO patent 
(GH GM KE, LS, MW, SD, SZ, UG, ZW), Eurasian patent 
AM, AZ, BY, KG, KZ, MD, RU. TJ, TM), European patent 
(AT BE CH CY, DE, DK, ES, FI, FR, GB, GR, IE, IT, 
LU MC NL*PT, SE), OAPI patent (BF, BJ, CF, CG, CI, 
CM GA, GN, GW, ML, MR, NE. SN, TD. TG). 



Published^^ imernalionQ i se arch report and to be republished 



upon receipt of that report. 



(54) TUle: METHOD AND SYSTEM FOR CONDUCTING ELECTRONIC COMMERCE TRANSACTIONS 

(57) Abstract 

A system and method for conducing Tronic 
merchant on a commerce server. The merchant also defines paymen P ^^^f server and l e \ tm . The merchant preferably 
merchant. The merchant, in turn, » provided w.th a sa]c . A customer viewing the merchant's web s.te 

publishes this reference at the merchant's web s.te on a web is put in contact with the commerce server and 

indicates a desire to purchase the item by selectmg Reference .^^f of ptymeat options. The customer preferably 

is provided with information from the commerce server ^abou tte .tern and s&vtn a P y fc 
selects a payment option and provides the ^™\ r ^™mvcc transaction. The commerce server then notifies 
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METHOD AND SYSTEM FOR CONDUCTING 
ELECTRONIC COMMERCE TRANSACTIONS 

Cross-Reference to Related application 
This application is a continuation-in-part of U.S. Provisional Application No. 
60/054,121, filed July 29, 1997. 

Background 

F , n p^ctmf k-vention 

This invention pertains in general to electronic commerce and in particular to a method 
and system for conducting electronic payment transactions via the Internet. 

ft APKGROU" " " F THF INVENTION 

Electronic commerce conducted over the Internet has become increasingly important 
over the last decade. Online merchants offer goods and services for sale or rent including 
physical objects such as compact disks, books, and clothing, and intellectual property such as 
streaming music and movies and electronic books. Physical items may be delivered to the 
customer via the mail or a variety of other shipping options. Intellectual property, m contrast, 
may be delivered to the customer by allowing a download via the file transfer protocol 
("FTP"), providing the customer with an access key, establishing a telnet session, or through 
some other form of electronic delivery. 

Typically, these goods and services are displayed on the merchant's web ate and a 
prospective customer views, select, and purchases the goods using web browsing software 
such as NETSCAPE NAVIGATOR* The customer usually pays for a product by establishing 
a secure connection with the merchant's web server and transmitting payment information, 
such as a credit card number, to the merchant. The merchant then uses back-end processing to 
verify the payment information and receive payment. For example, the merchant may use a 
secure telephone line or network link to contact the credit card issuer before accepting the 
customer's order. Eventually, the merchant and credit card issuer settle payment and the 
merchant delivers the product or service to the customer. 
D A difficulty with the above-described scenario is that each merchant must implement an 

inventory and payment database and a payment acceptance and verification system. For 
example the merchant must establish and maintain a database tracking sales, delivery, and 
payment information and product inventories in order to support the electronic commerce 
system There i. sienificant cost and complexity in maintaining this database, including the 
35 difficulty of integrating it with legacy accounting and fulfillment systems and aggravated by 
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the scarcity of truly skilled personnel. In addition, the merchant must design web pages to 
securely accept the order and payment information and implement the functionality to verify 
the payment. These tasks can be extremely difficult if the merchant accepts payment using 
many different methods, such as credit cards and electronic fund transfers, or accepts payment 
5 in more than one currency. Moreover, having a large number of separate payment acceptance 
systems on the Internet provides a greater opportunity for fraud and abuse because the flaws of 
each system can be exploited. 

Although Intemet-based electronic commerce clearinghouses have been developed to 
handle transactions from many different parties, these clearinghouses do not provide a 

10 convenient interface to the merchant. In addition, the merchant must still establish the 
payment, verification, and database systems described above. 

Accordingly, there is a need in the art for a method and system for conducting 
electronic commerce on the Internet which reduces the amount of work that must be performed 
by the online merchant. Preferably, the method and system will allow the merchant to easily 

1 5 and verifiably perform inventory, sales, and delivery tracking and transparently support 
different types of payments and currencies. 

Summary of the Invention 

The above needs are met by a method and system for conducting electronic commerce 
20 transactions that allows a merchant to easily sell a mix of physical and intangible items and 

supports sales, inventory, and delivery tracking and a variety of payment systems by having the 
merchant establish an account on a commerce server. The commerce server provides the 
merchant with inventory, accounting, and order management systems. Furthermore, the 
commerce server allows merchants to conduct electronic commerce with other merchants and 
25 vendors. 

The commerce server includes a web server providing web pages to the merchant. By 
using these web pages, the merchant establishes an account on the commerce server. Then, the 
merchant provides the commerce server with information about an item sold by the merchant, 
such as a plane ticket, clothing, a book, a software product, or playing time with an online 
30 game. The merchant also provides the commerce server with other attributes of the item from 
which the customer may select, for example, the quantity or duration of an item. In addition, 
the merchant supplies payment processing rules defining the payment options that are 
acceptable to the merchant, such as which currencies and payment systems are allowed and 
when or how often to bill the customer. 
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The commerce server preferably stores the information received from the merchant in 
an entry of a database. In one embodiment, the database entry categorizes the ,.em as a hard 
good soft good, or online good depending upon the delivery options available for the .ten, 
L commerce server, in addition, provides the merchant „i,h a "payment bunon" incWtng a 
universal resource locator ("URI^ that points to the commerce server and tncludes 
information allowing the commerce server to identify the database entry with whteh the 
payment button is associated. The merchant preferably publishes the payment button on the 
merchant's web site. 

The customer selects the payment button when the customer wishes to purchase the 
associated product. In response, the customer's computer is automatically directed to the web 
server managed by the commerce sewer and provided with the item informal entered by the 
merchant In addition, the customer is presented with the payment options allowed by the 
merchant'spaymentprocessingmle, Preferab,y, the customer then provides the web sewer 
with the payment information necessary to complete the transaction. 

When the merchant's payment terms specify that payment is required, the commerce 
server preferably identifies the remote payment system selected by the customer and contacts ,t 
tocompletetheelectroniccommerce transaction. Preferably, a module within the commerce 
server converts calls generated bythe commerce sewerinto the format usedby the selected 
payment system. Likewise, the module converts responses received from the payment system 
, LLformatusedbythecommerceserver. Then, the commerce server notifies the customer 
and the merchant of the result of the electronic commerce transaction and, if appropnate, 
delivers the item using one of the delivery options specified in the database. 

A method of conducting electronic commerce between a remote customer and a remote 
merchant m accordance with the present invention includes receiving information identifying 
5 anitemtobepurchasedbythe— 

method to be used by the customer to purchase the item, conducting a payment transact.cn 
with a remote payment system specified by the payment information, and proving the 
customer and the merchant with the result of the payment transaction. 

Similarly, computer program instructions for conducting electronic commerce 
,0 transactions in accordance with the present invention include instructions for stonng ttem 
information received from the merchant, instructions for issuing the merchant a reference to 
the stored item information, instructions for receiving an electronic commerce transacts 
identifier from the customer containing the reference to the stored item information issued to 
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the merchant, instructions for accepting payment information from the customer, and 
instructions for conducting the electronic commerce transaction with a remote payment system. 

Brief Description of the Drawings 
5 FIGURE 1 is a high-level block diagram of an electronic commerce system according 

to an embodiment of the present invention; 

FIGURE 2 is a high-level block diagram illustrating functional components of a 
commerce server according to an embodiment of the present invention; 

FIGURE 3 is a high-level block diagram of an entry in a database associated with the 
10 commerce server according to an embodiment of the present invention; 

FIGURE 4 is a flow diagram illustrating the interactions between the customer, 
merchant, commerce server, and payment system when completing a payment transaction 
according to an embodiment of the present invention; and 

FIGURE 5 illustrates an exemplary screen display of a web page seeking payment 
15 information from a customer; and 

FIGURE 6 illustrates an exemplary screen display of an order confirmation web page. 

Detailed Description of the Preferred Embodiment 
As used herein, the "Internet" refers to the global network of interconnected computer 

20 systems and the "World Wide Web" ("WWW") refers to the global hypertext system using the 
Internet as its transport mechanism. A "universal resource locator" ("URL") is a reference to a 
piece of information or a software function on a computer connected to the Internet. A "web 
server" is a program that accepts requests for information framed according to the HyperText 
Transport Protocol ("HTTP"). "Web pages" are the information supplied by the web server in 

25 response to the requests. The Common Gateway Interface ("CGI") is the standard that 

describes how the web server accesses external programs, usually called "CGI programs" or 
"CGI scripts," called by a web page. Of course, the present invention is not limited to the 
Internet and may be used with any digital network supporting electronic commerce. In a non- 
Internet-based system, the terms defined above also include the non-Internet-based equivalents 

30 for communicating between the various entities described herein. 

FIG. 1 is a high-level block diagram of an electronic commerce system 100 according 
to an embodiment of the present invention. Illustrated are a customer computer (sometimes 
referred to as "the customer") 110, a merchant web server (sometimes referred to as "the 
merchant") 1 12, and a commerce server ("CS") 114, all coupled to the Internet 1 16. In a 
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typ ical embodiment, the customer computer 1 K> is a per— computer having, among other 
things aprocessor,memory,s.oraged«vice,a„dmoni.or. The customer computer 
coupled to me Interne, 1 .6 via anetwork connection 1 18. The network connection may be, 
example a modem coupled to an analog telephone line, a digital subscriber line, a cable 
modem utilizing bandwidth on a cable television coaxial cable, a high speed digital line, or any 
other communications medium. Web browsing software, such as NETSCAPE 
NAVIGATOR*, preferably executes on the client computet and sends data from the chent 
computer UO to the merchant web sen-er 1 1 2 via the network connection 118 and Interne. 
, ,6 In another embodiment, the customer computer 1 10 is apalm-top device or personal 
digital system communing via radio waves with the Interne, 1 16 or another electrontc 
commerce system. 

The merchant web server 1 12 is preferably similar to the customer computer 110 except 
that it is has the processmg power and communications 116 bandw ld th to handle mulnple 
simultaneous customer transactions. The merchant 112 sells Hems, such as merchand.se, 
information, intellectual property, and/or services via a web site hosted on the merchant web 
server 1 12 The merchant's 1 12 web site may, for example, display a catalog of software 

tickel , or allow the customer 110 to play an online game, download a book or mustc, or access 

a database of information. 
, As used herein. ,he terms -customer" and "merchan," depend upon the specfic 

transacon being conducted. In a chain of commerce transactions, the "customer" in a fust 
transaction mav be a "merchan," in a second ,rar*ac«,o. For example, the customer 10 may 
ouy components of a product from several different vendors or merchants 1 12 usmg the 
electronic commerce system described herein and the, in turn, sel, ft. combined product v,a 
><; the customer's own web site and the CS 1 14. 

The merchant's web s,,e displays a. leas, one "payment button." A payment bunonts a 
graphic button, a region of a ,arger ^aphic, a text string, or another form of URL Unk whr ch 
, h e customer ,.0may"pr=ss"by selecting i, with a mouse, physical bu«o„, or other tnpu, 
device, in ano,he, embodiment, the payment button may be utilized on a non-Internet-based 
30 electronic commerce sys,em. In such an embodiment, the payment button is considered o 
..pressed" whenever a customer 1 1 0 expresses a desire to purchase an item. As d«cnb=d 
be,ow,thepay^e„tbu,,onispressedby*ecus«„mer.,Owhenmecus,omerllOw,shes,o 

purchase and pay for an hem d.splayed for sale on the merchant's web site. In a preferred 
embodiment, every rype of item for saie on the merchant's web site has a separate payment 



WO 99/07121 



PCT7US98/15884 



button. When a customer 1 10 wishes to purchase the product, the 1 10 customer presses the 
product's associated payment button. Then, the customer 1 10 is preferably presented with a 
menu allowing the customer 1 10 to specify attributes, such as quantity or duration, of the items 
that the customer 110 wishes to purchase. 
5 In another embodiment, the merchant web site has only one payment button or has only 

one payment button for each class of items for sale. In this embodiment, the customer 1 10 is 
preferably presented with a menu of choices after pressing the payment button. For example, 
the menu of choices may ask the customer 1 10 to identify a specific product or an attribute of a 
product, like color, that the customer 1 1 0 wishes to purchase. 
1 0 Every payment button has an associated URL that points to. information in the CS 1 14. 

Preferably, a database key that uniquely identifies the merchant 1 12 and/or item for sale is 
encoded within the URL. When the customer 110 presses the payment button, the customer 
110 is redirected to a web page provided by the CS 1 14 and specific to the merchant 1 12 
and/or item. 

1 5 In one embodiment, the CS 1 14 queries the customer for the quantity or duration of the 

item that the customer 110 wishes to purchase and payment information. The CS 1 14 receives 
the customer's responses and conducts the electronic commerce transaction according to 
payment processing rules and delivery options specified by the merchant 1 12. The CS 1 14 
records the transaction in its database and notifies the customer and merchant whether the 

20 transaction was successful. Accordingly, the merchant 1 12 is relieved of the responsibility of 
conducting the electronic commerce transaction with the customer 110. 

FIG. 2 is a high-level block diagram illustrating functional components of the CS 1 14 
and also illustrating a remote payment system 222 and a remote merchant 223 according to a 
preferred embodiment of the present invention. The CS 1 14 is preferably similar to the 

25 customer 110 and merchant 1 12 computers, except that the CS 1 14 has enough processing 
power and Internet 1 16 bandwidth to support many simultaneous payment button transactions 
as described herein. The functionality of the CS 1 14 described herein may be performed by 
hardware or software modules within the CS 1 14. In one embodiment of the present invention, 
the functionality of the CS 1 14 is provided by software applications executing on INTEL x86- 

30 or SUN MICROSYSTEMS SPARC-compatible hardware under control of MICROSOFT 
WINDOWS NT or a derivative of the UNIX operating system, such as SOLARIS 2.5.1. In 
another embodiment of the present invention, the functionality of the CS 1 14 is provided by a 
distributed computing system as described below, 

6 
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The remote payment system 222 is preferably a third-party payment gateway or system. 
The gateway or system is preferably connected to a financial transaction network, which, m 
turn typically links to computers at banks and other financial institutions for approval and 
settlement of electronic commerce transactions. Typical gateways or systems may mclude 
CYBERCASH, e-CASH, MONDEX, or SET. While only one payment system 222 is 
illustrated in FIG. 2, the CS 114 may be in communication with many different remote 
payment systems 222, either through a secure link on the Internet 11 6 or a dedicated secure 
link. Each payment system has an applications programming interface ("API")- By usmg the 
API, the CS 1 14 communicates with the payment system 222 and performs secure and 
verifiable payment transactions. 

The remote merchant 223 is preferably a merchant selling items via a web site as 
described above. The remote merchant 223 may have an account on the CS 1 14 or the 
merchant 2^3 may have an interface for selling items similar to the remote payment system 
222 In general, the remote merchant 223 is included in FIG. 2 to illustrate that the customer's 
, 10 electronic commerce transaction performed by the CS 1 14 may contact a remote payment 
system 222 and/or a remote merchant 223. 

The CS 1 14 includes a payment button transaction engine 210 which is coupled to a 
database 212 and a web server 214. A firewall 216 preferably sits between the web server 216 
and the transaction engine 210. While these functional components are illustrated m FIG. 2 as 
discrete entities, the CS 1 14 may be executed on a distributed computer system havmg a 
plurality of engines, databases, and web servers working together the perform the functus 
described herein. For example, one embodiment of the CS 114 uses multiple transacts 
engines 210 and web servers 214 and a single distributed database 212, thereby proving 
scalability to the CS 1 14. The number of web servers 214 and transaction engines 210 depends 
on the actual system load and the desire to achieve better performance through balancmg the 

transaction load across the system. 

The payment button transaction engine 210 includes a rules module 218 that controls 
the interactions and flows of information necessary to complete a payment transaction. In 
addition, the transaction engine 210 preferably includes a Payment Application Programmmg 
Interface ("PAPI") module 220 enabling communication between the CS 1 14 and the remote 
payment systems 222 and merchants 223. The PAPI module 220 abstracts the different APIs 
of each payment system 222 and merchant 223 into a smgle, higher level, PAPI that can 
interface with each of the payment systems 222 and merchants 223. The transaction engme 
210 performs payment transactions with a payment system 222 or merchant 223 by makmg 
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calls to the PAPI. The PAPI abstraction module 220 translates these calls into the specific API 
of the payment system 222 or merchant 223 being used for that transaction. The PAPI 
abstraction module 220 also translates data received from the payment system 222 or merchant 
223 into the format utilized by the transaction engine 210. Accordingly, the PAPI abstraction 
5 module 220 allows support for new payment systems 222 and merchants 223 to be added to the 
CS 1 1 4 by merely creating a new PAPI to payment system or merchant API mapping in the 
PAPI abstraction module 220. 

The payment button store module ("PB store") 224, in combination with the web server 
214, allows a merchant 1 12 to obtain a payment button. The web server 214 is preferably an 

1 0 industry standard web server such as the NETSCAPE ENTERPRISE SERVER or the 

APACHE web server. The web server 214 provides secure communication with the customer 
1 10 and preferably uses industry standard technologies including HyperText Markup Language 
("HTML"), and HTTP to deliver information to the customer 110. In addition, the web server 
preferably uses industry standard encryption techniques, including secure HTTP ("S-HTTP") 

1 5 and the secure sockets layer ("SSL"), to ensure that communications with the customer 1 1 0 are 
private. The firewall 216 allows only authorized communications between the web server 214 
and the transaction engine 210 and ensures that a malicious user cannot access or corrupt the 
transaction engine 210. 

The PB store 224 allows the merchant to purchase payment buttons and add product 

20 descriptions, merchant configurations, and other information to the database 212. In a 

preferred embodiment of the present invention, the merchant 1 12 accesses the PB store through 
a web site on the web server 214. The PB store module 224 captures the merchant 112 actions 
on the web server 234 and creates the appropriate entries in the database 212. 

In one embodiment of the present invention, the PB store web site describes the 

25 payment button mechanism, the services offered by the payment button vendor, and the costs 
of the services. In addition, the web site preferably has a merchant registration form 226 for 
f registering new merchants, a merchant renewal form 228 for renewing merchant registrations, 
and a payment button generation form 230 for issuing payment buttons to registered 
merchants. The forms preferably include CGI programs for performing the functionality 

30 described herein. 

The merchant registration form 226 allows the merchant 1 12 to input information 
identifying the merchant 1 12 and includes a payment button with which the merchant 1 12 can 
pay a registration fee. After the fee payment is verified, the merchant 1 12 is preferably issued 
a login/password pair and an account with the CS 1 14 through which the merchant 1 12 can 
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access the payment button generation form and maintain the merchant's account. Similarly, 
the merchant renewal form 228 preferably includes a payment button with which the merchant 

1 12 can pay a renewal fee. 

The payment button generation form 230 allows the merchant 1 12 to enter item 

5 description data, such as item names and descriptions, prices, types, and delivery options, and 
payment processing rules, such as supported credit cards, payment systems, and currencies. In 
addition, the payment processing rules may rank the payment systems in order of preference, 
describe when payment is required (e.g., the merchant may require billing after 90 days), 
and/or describe the quantity or duration of an item available for a certain price. In one 

10 embodiment of the present invention, the merchant 112 enters the item description data and 
payment processing rules by uploading a file to web site having the information in a 
standardized format. 

When entry of this data is completed, the payment button generation form 230 sends 
the data to the transaction engine 210, which stores the information in the database 212 at a 
15 location specified by a key. The transaction engine 210 passes the key back to the PB store 
web site, which provides the merchant with a payment button download page displaying the 
results of the payment button generation transaction. If the transaction was successful, the 
payment button download page includes the payment button issued to the merchant 112. The 
payment button has an associated URL that specifies the key. Accordingly, little or no 
20 engineering effort is required to maintain each merchant configuration on the CS 1 14. 

In one embodiment of the present invention, there are multiple PB store web sites 
communicatine with the database 212 through the transaction engine 210. When a payment 
button is created, the transaction engine 210 creates a field in the database 212 entry specifying 
the PB store that generated the payment button. Accordingly, payment buttons may be 
25 "branded" among different payment button vendors. 

The database 212 is preferably a robust relational database. A preferred embodiment of 
the present invention uses the ORACLE 7 database to implement the functionality described 
herein. The database 212 stores item descriptions, payment processing rules, and other 
information necessary to complete a payment transaction on behalf of a merchant 1 12. This 
30 merchant information is preferably accessed in the database by using a key assigned to each 
merchant 112 and/or item for sale. The database 212 is also used as a repository of transaction 
information including authorization logs, payment status and completion records, and other 
information required by the merchant 1 12 and the CS 1 14. 
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FIG. 3 is a high-level block diagram of functional components within the database 212. 
Illustrated therein are a database entry 300 including a primary entry 310 linked to at least one 
of three types of item entries 312, 314, 316. The primary entry 310 is the entry identified by 
the key provided to the merchant 112. Accordingly, the primary entry 3 1 0 is typically 
accessed either when the merchant 1 12 provides the key while using the PB store web site or 
when the customer 1 10 uses the URL provided by a payment button to purchase the item 
identified in the database entry 310. 

The primary entry 3 1 0 contains a field 3 1 8 storing the payment processing rules for the 
item as specified by the merchant 1 1 2 through the PB store. The primary entry 3 1 0 also 
contains a field 320 holding item type information as specified by the merchant 1 12. The item - 
type information preferably describes the item attributes input by the merchant 112. In 
addition, the item type information field 320 preferably contains at least one link to another 
database entry 3 1 2, 3 14, 3 1 6 describing delivery options for the item. 

The available delivery options for an item depend upon the type of item. FIG. 3 
illustrates three database entries 312, 314, 316 describing delivery options for hard, soft, and 
online items. However, an embodiment of the present invention may have many different 
types of items and corresponding delivery options. A hard item is typically a manufactured 
physical product such as clothing, a book, or a machine part. Accordingly, the entry 312 
holding delivery options 322 may list various shipping methods and companies available for 
delivering the hard item to the customer 110. 

A soft item, in contrast, is typically intangible intellectual property such as music, 
electronic books, or software. For example, the soft item may be a streaming music file that 
can be played by the customer 110. Accordingly, the entry 314 holding delivery options 324 
may list a URL or electronic key that can be provided to the customer to effectuate the 
purchase. For example, the options 324 may provide instructions for initiating an FTP session 
to download the purchased soft item to the customer's 110 computer system. 

An online item is typically access to an online service or other software executing 
remotely from the customer 110. For example, the online item may be access to an electronic 
database of information or an online game. Accordingly, the entry 316 holding delivery 
options 326 preferably includes instructions for allowing the customer 1 10 to access the online 
item. For example, the options 326 may provide instructions for initiating a telnet session with 
an electronic database for a limited duration of time. 

FIG. 4 is a flow diagram illustrating the interactions between the customer 1 1 0, 
merchant 1 12, CS 1 14, database 212 and a payment system 222 when completing a payment 

10 
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transaction according to a pr.fe.ed embodiment of ,he present invention, In the flow diagram, 
„me flows from th. top of me diagram to the bottom and horizon.* lines represent 
communications between the various entities. FIG. 4 illustrates only major interaettons 
between the entt.ies and does no, represent every interaction. In addition, HG. 4 illustrates a 

spec* tha, the payment transaction should be processed a. the time the customer s U0 order 

' S '""lltially the customer 1 10 is browsing the merchant's web site and decides to purchase 
an „em by oress.ng 4,0 the associated payment button, m response to the press, the 
merchant's web server 1 12 redirects 412 the customer's browser ,0 the locatton on the CS 114 
specified by the OKI associated w„h the payment button. The customer's browser fetches 
the referenced page from the CS 114. „,„ w , v 
The CS 1 1 4 parses the URL received from the customer 1 10 for the database 21 2 key 
corresponding to the item that the customer 1 10 wishes to purchase. Using this key, the CS 
, ,4 accesses 416 the database 212 and dynamically generates a web page indtcafngthe 
anributes and payment options available for the item as defined by the merchant 1 11 1. 
addition, the CS 1 .4 preferably determines the toguage utilized by ,h. customer 1 ,0 and 
currencies supported by the merchant 1 .2 and modifies the web page accordingly. Thts 
generated web page is sent 4. 8 to the customer 1.0. FIG. 5 illustrates an exemplary screen 
, display 500 of the web page seeking payment information from the customer , 10. 

The customer selects the desired item attributes and payment service, enters any 
necessary payment informal, such as a credit card or account number, and transmtts 420 
,hese data to the CS 1 ,4. The CS 1 14 stores 422 ,he received da,a in the database 2 2 and 
contacts the seiected payment system 222. As describe, above, the CS 1 ,4 
5 PAP1 module 220 to translate transaction calls made by the transaction ervgm. 210 mto the API 
of the selected payment system 222. TheCS 1,4 preferably stores 42« records of all 
commnnications with the payment system 222, customer 1 1 0, and merchant 1 12 .n the 
debase 2,2. Therefore, the database 2,2 can be used to reconstruct transaction hrstones , 
order to provide error tracking and accounting services. If the payment system 222 rejects 
!0 taction, the CS 114 publishes a web page to the customer indicating this resuH and 
presenting ahemative payment methods, if any (this interaction is no. shown m FIG. 4> 

If the payment system 222 approves the transaction, the CS dynarmcally generates a 
web page containing payment sums information and publishes 428 this information ,0 the 
customer 1 .0. This page preferab.y contarns a receipt or confirmation number generated by 
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the CS 1 14. In a preferred embodiment of the present invention, the confirmation number is a 
unique number encoding transaction, session, and merchant identifications and a time and date 
stamp. This confirmation number is preferably a key to a database entry holding the 
transaction information and can be used later by the merchant 1 12 and customer 1 10 to confirm 
5 payment, to query the CS 1 14 for payment status information, and to use the CS 1 14 to query 
the payment system for account status information. The web page also preferably contains any 
other information required by the merchant 112 and a link to a confirmation page on the 
merchant's web site 1 12. FIG. 6 illustrates an exemplary screen display 600 of an order 
confirmation web page. 

1 0 - The CS 1 14 also notifies 428 the merchant 1 12 that payment was accepted and provides _ 
the same receipt or confirmation number as was provided to the customer 1 10. In one 
embodiment, this notification is performed via a secure electronic mail message. Accordingly, 
both the customer 110 and merchant 1 12 are notified that the purchase was made. 

Finally, the customer 110 fetches 430 the confirmation web page on the merchant's 

15 web site. Preferably, this web page provides the customer 1 10 with additional information 
about the purchase or any other information which the merchant 112 desires to provide. 

In summary, the present invention is a system, method, and computer program 
instructions for conducting electronic commerce transactions via the Internet or any electronic 
communication system. The merchant 112 opens an account on the CS 1 14 and supplies 

20 information about items sold by the merchant 112. The CS 1 14 stores this information in a 
database 212 entry and issues the merchant 112 a URL containing the key to database entry. 
The merchant 112 supplies this URL to customers wishing to purchase an item, causing a 
customer 1 10 to be connected to the CS 114. The CS 1 14 collects payment information from 
the customer 110, conducts the electronic commerce transaction with a remote payment system 

25 222, and notifies the customer 1 10 and merchant 1 12 of the result. 
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Claims 

1 claim: 

1 . A computer system for supporting electronic commerce transactions between a 
customer and a remote merchant, the computer system comprising: 

a database having an entry including merchant information identifying an item 

offered for sale by the remote merchant; and 
a transaction engine in communication with the database and a remote payment 
system for performing an electronic commerce transaction, the transaction 
engine comprising: 

a first module for receiving an electronic commerce transaction identifier 

from the customer, the electronic commerce transaction identifier 

specifying the entry in the database; 
a second module for accepting payment information from the customer, the 

payment information identifying the remote payment system; and 
a third module for performing the electronic commerce transaction with the 

remote payment system using the payment information received 

from the customer. 

2. The computer system of claim 1 , wherein the transaction engine further 
comprises: 

a fourth module for notifying the remote merchant and the customer of a result of 
the electronic commerce transaction. 

3 . The computer system of claim 1 , further comprising: 

a web server in communication with the transaction engine for communicating with 

the remote merchant and customer; and 
a firewall between the web server and the transaction engine for securing 

communications between the web server and the transaction engine. 

4. The computer system of claim 3, wherein the transaction engine further 
comprises: 

a fifth module for dynamically generating a web page from the entry in the database 
and providing the web page to the customer via the web server, the web 
page providing information about the item offered for sale by the remote 
13 
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merchant and facilitating collection of the payment information from the 
customer. 

5. The computer system of claim 3, wherein the computer system further 
comprises: 

a sixth module for accepting the merchant information identifying the item offered 
for sale by the remote merchant via the web server, creating the database 
entry for holding the merchant information, and providing the remote 
merchant with a reference to the database entry. 

6. The computer system of claim 1 , wherein the electronic commerce transaction 
identifier is a URL identifying the computer system and including a key to the entry in the 
database. 

7. The computer system of claim 1 , wherein the database further comprises: 

an entry specifying payment processing rules defined by the remote merchant; and 
an entry specifying delivery options for the item offered for sale by the remote 
merchant. 

8. The computer system of claim 1, wherein there are a plurality of available 
remote payment systems and wherein the second module for accepting payment information 
from the customer accepts payment information identifying one of the available remote 
payment systems. 

9. The computer system of claim 1 , wherein the transaction engine is executed by 
a plurality of distributed computer systems. 

10. A method of conducting electronic commerce between a remote customer and a 
remote merchant, the method comprising the steps of: 

receiving information identifying an item to be purchased by the remote customer; 
receiving payment information specifying a payment method to be used by the 

remote customer to purchase the item; 
conducting a payment transaction with a remote payment system specified by the 

payment information; and 
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providing the remote customer and the remote merchant with a result of the 
payment transaction. 

11. The method of claim 1 0, further comprising the steps of: 

receiving information about the item to be purchased from the remote merchant; 
storing the information about the item to be purchased at a specified location; and 
providing the remote merchant with a reference to the specified location. 

12. The method of claim 1 1 , wherein the remote merchant provides the reference to 
the specified location to the remote customer responsive to the remote customer desiring to 
purchase the item. 

13. The method of claim 1 0, further comprising the step of: 

providing the remote customer with a list of item attributes from which the 
customer can select. 

14. The method of claim 10, wherein the step of receiving information identifying 
the item to be purchased by the remote customer comprises the steps of: 

receiving payment processing rules specifying payment options available for 

purchasing the item; and 
receiving delivery options for the item. 

15. A computer-readable medium having computer instructions encoded thereon for 
conducting electronic commerce transactions between a remote merchant and a remote 
customer, the computer instructions comprising: 

instructions for storing item information received from the remote merchant; 
instructions for issuing the remote merchant a reference to the stored item 
information; 

instructions for receiving an electronic commerce transaction identifier from the 
remote customer containing the reference to the stored item information 
issued to the remote merchant; 

instructions for accepting payment information from the remote customer, the 
payment information identifying a remote payment system; and 
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instructions for conducting the electronic commerce transaction with the remote 
payment system using the payment information received from the remote 
customer. 

16. The computer-readable medium of claim 15, wherein the instructions further 
5 comprise: 

instructions for notifying the remote merchant and the remote customer of a result 
of the electronic commerce transaction. 

17. The computer-readable medium of claim 15, wherein the instructions for storing 
item information received from the remote merchant comprise: 

1 0 instructions for receiving payment processing rules from the remote merchant 

specifying payment options for the electronic commerce transaction; and 
instructions for receiving delivery rules from the remote merchant specifying 
delivery options for the electronic commerce transaction. 
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PLEASE REVIEW THIS PAGE AND ENSURE IT IS CORRECT. 
BEFORE COMPLETING YOUR PAYMENT DETAILS. 




SKU 
2121 



QTY 
2 



ITEMS UNIT PRICE EXTENDED PRICE 

SPROCKET $8.99 $17.98 
SUBTOTAL: $17.98 
SHIPPING: $ 3.95 
TAX: $ 1-72 

TOTAL: $23.65 



BILLING ADDRESS 



SHIPPING ADDRESS 



FIRST NAME: 
LAST NAME: 
COMPANY: 
ADDRESS 1: 
ADDRESS2: 
CITY: 
STATE: 
ZIP: 



JOE 

BLOGGS 

GLOBAL BAKING COMPANY 
2252 N. PETERS RD. 

SAN JOSE 
CA 

96025-5123 



PAYMENT INFORMATION 

_ nmc MASTERCARD 
PAYMENT TYPE: . 
NAMEAS IT APPEARS ON CARD » 

NUMBER # i -l/l 1 

EXPIRATION DATE I •/ 1 1 

| MAKE CORRECTIONS! pPROCESS ORDfcK | 




FIG.5 
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--THANK YOU FOR YOUR ORDER - - 
RECEIPT NUMBER: 1 587-8029-5 

GLOBAL SPROKETS COMPANY INC. 

2243 E. WISTENA WAY, BOSTON, MA 24248, USA 

EMAIL: INFO@SPROKETS.COM. WEB: HTTP//WWW.SPROKETS.COM 

| PRODUCTS ORDERED 1 

SKU QTY ITEMS UNIT PRICE TOTAL PRICE 

2121 2 SPROCKET $8.99 $17.98 

SUBTOTAL: $17.98 

SHIPPING: $ 3.95 

TAX: $ 1.72 

TOTAL: $23.65 



BILLING ADDRESS 



SHIPPING ADDRESS 



FIRST NAME: 
LAST NAME: 
COMPANY: 
ADDRESS 1: 
ADDRESS2: 
CITY: 
STATE: 
ZIP: 



JOE 

BLOGGS 

GLOBAL BAKING COMPANY 
2252 N. PETERS RD. 

SAN JOSE 
CA 

96025-5123 



PAYMENT INFORMATION 



PAYMENT TYPE: MASTERCARD 
YOUR CARD HAS BEEN CHARGED: $23.65 



CUSTOMER INFORMATION 



WE AIM TO SHIP ITEMS WITHIN 10 DAYS 
THANK YOU FOR YOUR ORDER! 
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